18:06:46 #startmeeting 18:06:46 Meeting started Mon Oct 27 18:06:46 2014 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:06:46 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:07:28 So last week GeKo and I decided to aim for Thursday for a rlease #13443 18:07:37 by setting the pref 18:07:50 I should have 4.0 builds by tonight 18:07:54 err 4.0.1 18:09:06 I also have almost finished updating the design doc for 4.0 18:09:57 I think it might also be good to aim for a 4.5.0-alpha with https://trac.torproject.org/projects/tor/query?keywords=~tbb-4.5-alpha in it 18:10:14 since we're basically waiting for Thursday for Geko to come back anyway.. 18:10:30 though if anyone else wants to sign a build for 4.0.1, that could help us release earlier 18:11:14 that's it for me 18:11:37 When will GeKo be back? We wlll have to wait until he gets back to send bits to tor-qa, right? 18:12:12 (Kathy says he will be back Thursday) 18:12:21 * nickm asks if TBB4.0.1 will have Tor 0.2.5.10 18:12:39 no, we can send it out before him, but users will expect his sigs on the sha256sums.txt files 18:12:49 as will things like Tor-browser-launcher 18:12:58 nickm: yes, it does 18:13:26 Regarding #13443, I thought this comment was interesting: https://trac.torproject.org/projects/tor/ticket/13443?cversion=1&cnum_hist=42#comment:42 . Has anyone tried looking at getting SEH to work with mingw? 18:13:36 Probably changing signatures will annoy/confuse people, so it makes sense to wait for him to sign. 18:14:40 arthuredelstein: yes, I saw that. I think the SEH support in MinGW is incomplete, which is why FF builds without it by default. I am not sure how incomplete, though 18:15:56 I spent some time last week trying to build a debug version of .mozconfig-mingw using the gitian builder, but it kept failing. Has anyone gotten this to work? 18:16:08 Non-debug builds fine 18:17:15 I don't remember if I've tried that. does the build itself fail, you mean? 18:17:22 yes 18:18:03 mikeperry: fwiw, firefox *always* builds with -fno-exceptions if the host compiler is gcc 18:18:08 even on lenooks 18:18:35 yeah 18:21:24 arthuredelstein: GeKo has been doing much of the MinGW wrangling lately.. I know he had to pick the odd commit of it that we used because it was needed to build FF at all.. it's possible there simply are more bugs/incomplete feature support :/ 18:21:39 (we are not using a release version of mingw) 18:22:13 Just saying, there is nothing at the help desk side we need to report. 18:23:04 * sherief is around if needed 18:23:20 ok, thanks 18:23:29 who wants to go next? 18:24:07 uh, I may have another branch for a future alpha 18:24:17 wiht a new firewall helper 18:24:25 but I need to talk to dcf about how we want to do that 18:24:46 so "in the future" sort of thing 18:24:50 ok 18:25:12 * nickm will put out 0.2.6.1-alpha later this week, I hope. 18:25:27 Should we make a plan for getting TBB alphas released that will contain it? 18:25:35 I am about to branch off a maint-4.0 so that we can merge #12903 for 4.5 18:25:56 \o/ 18:26:26 !! :D 18:26:29 sounds like an opportunity to me. Do we need to coordinate more than that? 18:26:30 how many obfs4 bridges are there now? 18:26:53 no idea 18:26:56 in the bundle 3 18:27:08 mine isn't exactly high capacity 18:27:12 nickm, i meant is 0.2.4.25 no longer being supported, or will you continue supporting 0.2.4 for a while? I don't want to distribute anything that you guys are ot actively working on 18:27:33 define "supported" 18:27:34 blueness: 0.2.4.25 is supported, but its days are numbered. 18:27:39 0.2.5.x is the new hotness 18:28:00 nickm, true, let me ask even more specifically ... should i yank 0.2.4.25 from the gentoo tree today? 18:28:07 nickm: Well, if you tag by tomorrow night, it has a good chance of making it into 4.5.0-alpha. otherwise, you may end up waiting for a bit 18:28:17 define "a bit" ? 18:28:17 i can go next, or whenever 18:28:25 blueness: not today 18:28:26 * armadev drops in 18:29:00 nickm: maybe even if you tag by Wednesday 18:29:12 isis: go ahead 18:31:24 i spent last week reporting on #12193 some of the reasons why i am starting to think that Persona isn't really moldable into what we what w.r.t. armadev's "Helping internet services accept anonymous users" blog post 18:32:27 i also had to do a bunch of bridgdb related things, like keeping an eye on the ongoing bridge-reachability hackathon to make sure nothing i care about gets completely borked 18:32:40 it does sound like from your update on that ticket they managed to mess up forwards-compatibility with their own native implementation 18:32:57 which is just all kinds of sad 18:33:30 yes, i believe so. there are ~16 steps there that people can take in order to play with the system and get a feel for how much is broken 18:33:37 seems like it is not only "community support" at this point, it's "community finish this please" :/ 18:33:44 nickm, thanks, i didn't think so. i'll just keep my ears open. right now gentoo has both 0.2.4.25 and 0.2.5.10 in the mirrors, but the former is marked "stable" while the latter is marke experimental 18:33:54 heh, yeah, that would be more accurate 18:34:10 blueness: Okay. Maybe in 2-4 weeks, call 0.2.4 "old-stable" and 0.2.5 "stable"? 18:34:12 blueness: does gentoo have an oldstable concept? 18:34:17 hah! 18:34:37 Sebastian, there is no oldstable, but i can have more than one stable 18:34:47 the Persona server-side IdP documentation + code was mostly vaporware and wrong documentation 18:34:48 stable just means "its cooked a while and now we think its done" 18:35:06 the primary IdP stuff is just non-existent 18:35:07 so i will mark 0.2.5.10 stable in 4 weeks and yank 0.2.4.35 18:35:19 or call them both stable; up to you 18:35:24 it might be reasonable for a gentoo packager to wait a bit after upstream decided stability is achieved. 18:35:57 i meant to send an email to tor-internal asking about my other two TBB deliverables related to Persona, and how y'all think i should finish this 18:36:23 isis: well, if you want to spend your third deliverable investigating other credential schemes that might work, that seems OK to me. 18:36:31 Sebastian, nickm the rule is 4 weeks in testing and then stabilize unless its a security issue, then stabilize immediately with reasonable testing 18:37:15 mikeperry: okay, the second deliverable, for setting up the CAPTCHA system for Persona, that money can go towards something else now 18:37:33 it would be a waste of time and money for me to work on it, i think 18:38:16 will Sponsor P be okay with that? would they like some sort of document explaining why we didn't do it? 18:38:55 I am not actually sure what documentation they need along with invoicing.. 18:39:43 if they need anything, just let me know, i'd be happy to write a short summary document explaining why the experiment rather dead-ended 18:42:42 i haven't followed things in detail, but in general we should either give them something else that's better than what we said we'd do, and explain why we did that instead, or at least write up in pretty good detail why we decided not to do the thing we said we'd do 18:43:06 it's too easy to just say "oops decided not to", and hard for them to distinguish "ran out of time pretended it was a bad idea" from "oops decided not to" 18:44:22 well, we have a testing server, which is what we said we would do as part of the investigation. I'm looking at the proposal doc now 18:44:48 it says we'd have captcha support in that testing server, but it does seem silly to add that to an already failed experiment with the vanilla testing server 18:45:18 but we should write something up describing why we think it's a failed experiment 18:45:31 and I think it would also be great to have something else we could point at instead 18:45:48 in terms of some other anonymous credential system 18:47:09 in my free time in the last year, i have been toying with implementing *real* anonymous credentials, and i have tested and looked into many more-or-less experimental pairing-based cryptography libraries 18:47:17 I just bought some FIDO devices, and planned on investigating them, but they provide 'login', just two factor really. (Although maybe they could do login but not enrollment...?) 18:47:27 *they don't provide 18:47:41 because in my view, the whole point of this was to prototype something that might help solve the abuse problem, so if we fail and say "it's hopeless", that's a way worse failure than "but this other thing seems like something we could try for these reasons" 18:47:52 the first of which was libpbc, as i've already mentioned, then matthew green's CHARM which was also too experimental/researchy 18:48:10 i found one a couple months ago which, however, is excellent 18:48:15 called RELIC 18:48:24 https://github.com/relic-toolkit/relic 18:49:13 the lead developer is very smart and fast at answering questions 18:49:52 and his some of his code for algorithms holds up better than either OpenSSL or GnuPG's code 18:50:25 which isn't the highest bar to set, of course, but perhaps help show that it's not just researchy-academic code 18:51:08 RELIC is the new tinyPBC implementation, meant for embedded systems https://sites.google.com/site/tinypbc/ 18:51:19 i've always assumed that the actual crypto primitives were not the weak link here, and "there is nothing that uses them" was the real problem. 18:51:51 well, there's also "there's nothing that even implements them" 18:52:18 (That's one of the big reasons I'm curious about FIDO. It's built into Chrome, it will come to Firefox, Google.com supports it, Paypal will, Facebook will...) 18:52:34 the first version of zerocoin used at some point, every primitive i need 18:52:50 at least, nothing that isn't research code that executes in reasonable timescales 18:53:08 they went a different route with using libsnark because it wasn't fast enough or small enough to put in a blockchain 18:53:24 but anyway, it seems clear that persona is worse than that, because the few sites that use it, we'd have to break, just to get them to use the native RSA code in Firefox 18:53:47 so we're starting from square -1 with Persona 18:53:50 instead of square 1 18:54:02 mikeperry: we don't need that kind of performance if we're doing it in the background in the browser, and storing it where we'd normally store a giant RSA cert 18:54:40 i hope i am not blocking anyone else from reporting back 18:55:10 I have to vanish in like 5 minutes. I think we need to decide a plan for this after the meeting 18:55:33 okay, that's fine with me. :) 18:55:33 * MarkSmith would like to give a quick report 18:55:35 who will be able to stay for the rest of the meeting and make sure it progresses? 18:55:47 i can, since i held it up 18:55:58 * isis mumbles apologies again 18:56:12 MarkSmith: please, go ahead 18:56:22 Last week Kathy and I assisted with the TB 4.0 release fallout by triaging various tickets. 18:56:32 I also answered a few Tor Browser questions on https://tor.stackexchange.com/ 18:56:39 We fixed #10391 (already merged by Mike -- thanks!) 18:56:53 Oops; wrong bug number. 18:57:25 We fixed the bug related to "Tor" vs "Tor Browser" in Windows resources. 18:57:32 We also spent some time on updater issues, including #13432 and #13512. And we reviewed boklm's changes for #13324. 18:57:49 This week we plan to continue to help with bug triage. 18:57:56 We will also look at #13379. We will need some assistance with the design to make sure security requirements are met. 18:58:33 We will probably start by asking mikeperry what he has in mind for the signed MAR files implementation. 18:58:49 That's all for us. 18:59:28 ok. yeah, I guess the plan for that will depend on how the tools work 18:59:38 and if we can sign them after we generate both full and incremental mars 18:59:51 because I think that would be the easiest workflow 19:00:03 build, reproduce, match other builders, then the magic signing key signs them all 19:00:18 OK. I know you have to leave, so we will definitely ping you soon to discuss this more. 19:00:19 and then they don't match, but at least are signed 19:00:45 bonus points if we can "unsign " them to verify that they still match, but I would be surprised if the mar tools supported that 19:01:26 "unsign" is an interesting concept given our reproducible build focus. 19:01:37 the signature will be included inside the .mar file ? 19:02:53 As far as I know, Mozilla only uses MAR file sigs on Windows, so probably they use a Windows resource (I am not sure)? 19:02:57 Will find out. 19:03:14 ok 19:03:43 * boklm can go next 19:04:00 (the bug I meant to mention is #13091) 19:04:35 So this week I have mainly been working on tor-messenger build, and I made a patch for ticket #13015 (although I still need to make a build to check everything is working). 19:04:55 This week I plan to help with generation of incremental mars for 4.5 alpha. 19:05:15 that's it for me 19:05:37 boklm: unrelated question: do we have a windows test machine? 19:06:05 I was thinking it would be nice to run mochitests etc on mingw build to help catch bugs like #13443 19:06:30 arthuredelstein: yes, we have a windows test machine, although tests are not running on it yet 19:07:26 Cool. :) 19:08:10 Also, I was wondering if you have had a chance to run your per-patch mochitests on the 4.0 branch? I would like to help work on fixing broken tests 19:08:56 arthuredelstein: I will launch it on the 4.0 branch and send you the link 19:09:10 Awesome -- thanks so much 19:09:25 (re: someone else signing in GeKo's place this week) it looks like we would not break micahflee's torbrowser-launcher by doing so. torbrowser-launcher only uses helix's signature `sha256sums.txt.asc`: https://github.com/micahflee/torbrowser-launcher/blob/master/torbrowser_launcher/common.py#L122 19:09:43 not sure if there are other important things which would break 19:10:23 I have the minorest of updates. 19:10:29 I'm not sure if it's helpful to anyone, as GeKo said he did it (somewhere...), but I rebased my 64bit Mac patches onto ESR31 and got it working ~5 minutes ago. I'll be pushing them to github later today. 19:10:46 I'm going to use that as the base for trying to get the ctamlloc library working on Mac. 19:11:04 (that's it) 19:11:16 tjr: excellent 19:11:42 A question for mikeperry or GeKo would be: When do we plan to switch to 64-bit builds for Mac OS? (or maybe somewhere here knows the answer) 19:11:53 someone here, I meant to say 19:12:07 Mike indicated that the last release would be the last 32 bit release for Mac in the blog post 19:12:17 Barring user feedback that that's a horrible idea 19:13:18 hmm... the blog post says "very soon" 19:14:06 perhaps 4.5 is a good mark to aim for switching, that way we could warn people of a definitive time when the switch will happen? 19:14:07 I guess I am wondering if it will be in 4.5 (that might be a good goal, but probably it is too late for the first alpha) 19:14:17 agreed ;) 19:16:08 Ah, I was going partly from memory. Maybe he said it in chat, or maybe I didn't remember right 19:17:23 thanks for working on that tjr 19:18:26 boklm, you had finished your reportback, yes? does someone else want to go next? 19:18:26 In starts and fits, distracted by shiny things like Directory Authorites :-p 19:18:46 isis: yes 19:18:55 * arthuredelstein can go 19:19:06 tjr: your posts on trying to run a separate network were also interesting! :) 19:19:23 arthuredelstein: ok 19:19:28 Last week I worked on upgrading my patch for #8641 19:19:46 which simplifies it considerably 19:20:09 And I worked on making my patch at https://bugzilla.mozilla.org/show_bug.cgi?id=436344 acceptable to Mozilla. Getting close now... 19:20:39 And finally I worked on getting mingw debug build working, but as mentioned, no success so far 19:20:57 that's all for me 19:21:39 Oh yeah, this week I will try and work on getting more patches to land at Mozilla and look into fixing some of our mochitests 19:22:04 nice :) 19:25:38 arthuredelstein: wow, the UI for #8641 is awesome looking 19:25:47 thanks :) 19:26:06 Actually, I had a crazy thought of moving it to a drop down from an icon in the URL bar 19:26:24 To the left of the lock icon 19:26:44 I wonder if it would be more intuitive to users then 19:28:16 hmm... i think so, perhaps. but in the crazy case, you'd also end up with |CerticomSSL> little-canvas-fingerprinting-palette-icon little-circuit-status-icon little-lock-icon https://blahblah.com| 19:28:58 Yikes 19:29:03 Where it is now, I wonder if people will expect to be able to interact with it because it is in the Torbutton menu? (don't get me wrong; I really like what you have done) 19:29:03 arthuredelstein: would it be much harder to do it that way? 19:29:19 MarkSmith: That's my concern as well. 19:29:33 isis: I'm not sure, I think it's possible 19:29:47 It could be part of the Page Info window but people might not notice it at all among all of Mozilla's stuff. 19:30:04 (similar to the point isis made about things located near the lock icon). Hmmm. 19:30:31 It might be interactive in the future, if people want to change exit nodes, for example. 19:32:27 i will think about this more and try to imagine where i might expect it to be 19:32:52 thanks! 19:33:15 and thanks for reminding me that my canvas-fingerprinting UI got pretty borked by the ESR31 upgrade... need to make tickets 19:34:03 ok, who wants to go next? 19:36:53 did we miss anyone? are there any support desk reports? 19:37:53 tjr: do you know if there is a ticket for switching to 64-bit mac builds for TBB? 19:38:45 Not off the top of my head, let me look... 19:40:03 I think it's #10138 19:40:32 Note that GeKo's vision for 64 bit builds are using clang, which is harder than using gcc. 19:40:54 tjr: awesome, thanks! i was searching for "64 osx" and getting zero matches :/ 19:41:02 I think there's consensus that of {32bit, gcc, and clgang} gcc is preferable to 32bit, and you're going to release with that until clang is ready 19:42:45 okay, last chance to say something for the meeting, or forever remain in pisces 19:43:01 #endmeeting 19:43:32 * isis slaps MeetBot with a large fish 19:43:42 mikeperry: *ahem* ↑↑ 19:44:05 #endmeeting