18:06:46 <mikeperry> #startmeeting
18:06:46 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:07:28 <mikeperry> So last week GeKo and I decided to aim for Thursday for a rlease #13443
18:07:37 <mikeperry> by setting the pref
18:07:50 <mikeperry> I should have 4.0 builds by tonight
18:07:54 <mikeperry> err 4.0.1
18:09:06 <mikeperry> I also have almost finished updating the design doc for 4.0
18:09:57 <mikeperry> 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 <mikeperry> since we're basically waiting for Thursday for Geko to come back anyway..
18:10:30 <mikeperry> though if anyone else wants to sign a build for 4.0.1, that could help us release earlier
18:11:14 <mikeperry> that's it for me
18:11:37 <MarkSmith> When will GeKo be back?  We wlll have to wait until he gets back to send bits to tor-qa, right?
18:12:12 <MarkSmith> (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 <mikeperry> no, we can send it out before him, but users will expect his sigs on the sha256sums.txt files
18:12:49 <mikeperry> as will things like Tor-browser-launcher
18:12:58 <mikeperry> nickm: yes, it does
18:13:26 <arthuredelstein> 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 <MarkSmith> Probably changing signatures will annoy/confuse people, so it makes sense to wait for him to sign.
18:14:40 <mikeperry> 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 <arthuredelstein> 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 <arthuredelstein> Non-debug builds fine
18:17:15 <mikeperry> I don't remember if I've tried that. does the build itself fail, you mean?
18:17:22 <arthuredelstein> yes
18:18:03 <Yawning> mikeperry: fwiw, firefox *always* builds with -fno-exceptions if the host compiler is gcc
18:18:08 <Yawning> even on lenooks
18:18:35 <mikeperry> yeah
18:21:24 <mikeperry> 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 <mikeperry> (we are not using a release version of mingw)
18:22:13 <sherief> 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 <mikeperry> ok, thanks
18:23:29 <mikeperry> who wants to go next?
18:24:07 <Yawning> uh, I may have another branch for a future alpha
18:24:17 <Yawning> wiht a new firewall helper
18:24:25 <Yawning> but I need to talk to dcf about how we want to do that
18:24:46 <Yawning> so "in the future" sort of thing
18:24:50 <mikeperry> ok
18:25:12 * nickm will put out 0.2.6.1-alpha later this week, I hope.
18:25:27 <nickm> Should we make a plan for getting TBB alphas released that will contain it?
18:25:35 <mikeperry> I am about to branch off a maint-4.0 so that we can merge #12903 for 4.5
18:25:56 <Yawning> \o/
18:26:26 <isis> !! :D
18:26:29 <nickm> sounds like an opportunity to me. Do we need to coordinate more than that?
18:26:30 <isis> how many obfs4 bridges are there now?
18:26:53 <Yawning> no idea
18:26:56 <Yawning> in the bundle 3
18:27:08 <Yawning> mine isn't exactly high capacity
18:27:12 <blueness> 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 <Yawning> define "supported"
18:27:34 <nickm> blueness: 0.2.4.25 is supported, but its days are numbered.
18:27:39 <nickm> 0.2.5.x is the new hotness
18:28:00 <blueness> nickm, true, let me ask even more specifically ... should i yank 0.2.4.25 from the gentoo tree today?
18:28:07 <mikeperry> 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 <nickm> define "a bit" ?
18:28:17 <isis> i can go next, or whenever
18:28:25 <nickm> blueness: not today
18:28:26 * armadev drops in
18:29:00 <mikeperry> nickm: maybe even if you tag by Wednesday
18:29:12 <mikeperry> isis: go ahead
18:31:24 <isis> 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 <isis> 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 <mikeperry> 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 <mikeperry> which is just all kinds of sad
18:33:30 <isis> 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 <mikeperry> seems like it is not only "community support" at this point, it's "community finish this please" :/
18:33:44 <blueness> 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 <isis> heh, yeah, that would be more accurate
18:34:10 <nickm> blueness: Okay.  Maybe in 2-4 weeks, call 0.2.4 "old-stable" and 0.2.5 "stable"?
18:34:12 <Sebastian> blueness: does gentoo have an oldstable concept?
18:34:17 <Sebastian> hah!
18:34:37 <blueness> Sebastian, there is no oldstable, but i can have more than one stable
18:34:47 <isis> the Persona server-side IdP documentation + code was mostly vaporware and wrong documentation
18:34:48 <blueness> stable just means "its cooked a while and now we think its done"
18:35:06 <isis> the primary IdP stuff is just non-existent
18:35:07 <blueness> so i will mark 0.2.5.10 stable in 4 weeks and yank 0.2.4.35
18:35:19 <nickm> or call them both stable; up to you
18:35:24 <Sebastian> it might be reasonable for a gentoo packager to wait a bit after upstream decided stability is achieved.
18:35:57 <isis> 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 <mikeperry> 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 <blueness> 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 <isis> mikeperry: okay, the second deliverable, for setting up the CAPTCHA system for Persona, that money can go towards something else now
18:37:33 <isis> it would be a waste of time and money for me to work on it, i think
18:38:16 <isis> will Sponsor P be okay with that? would they like some sort of document explaining why we didn't do it?
18:38:55 <mikeperry> I am not actually sure what documentation they need along with invoicing..
18:39:43 <isis> 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 <armadev> 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 <armadev> 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 <mikeperry> 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 <mikeperry> 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 <mikeperry> but we should write something up describing why we think it's a failed experiment
18:45:31 <mikeperry> and I think it would also be great to have something else we could point at instead
18:45:48 <mikeperry> in terms of some other anonymous credential system
18:47:09 <isis> 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 <tjr> 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 <tjr> *they don't provide
18:47:41 <mikeperry> 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 <isis> 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 <isis> i found one a couple months ago which, however, is excellent
18:48:15 <isis> called RELIC
18:48:24 <isis> https://github.com/relic-toolkit/relic
18:49:13 <isis> the lead developer is very smart and fast at answering questions
18:49:52 <isis> and his some of his code for algorithms holds up better than either OpenSSL or GnuPG's code
18:50:25 <isis> 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 <isis> RELIC is the new tinyPBC implementation, meant for embedded systems https://sites.google.com/site/tinypbc/
18:51:19 <armadev> 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 <mikeperry> well, there's also "there's nothing that even implements them"
18:52:18 <tjr> (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 <isis> the first version of zerocoin used at some point, every primitive i need
18:52:50 <mikeperry> at least, nothing that isn't research code that executes in reasonable timescales
18:53:08 <isis> 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 <mikeperry> 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 <mikeperry> so we're starting from square -1 with Persona
18:53:50 <mikeperry> instead of square 1
18:54:02 <isis> 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 <isis> i hope i am not blocking anyone else from reporting back
18:55:10 <mikeperry> I have to vanish in like 5 minutes. I think we need to decide a plan for this after the meeting
18:55:33 <isis> okay, that's fine with me. :)
18:55:33 * MarkSmith would like to give a quick report
18:55:35 <mikeperry> who will be able to stay for the rest of the meeting and make sure it progresses?
18:55:47 <isis> i can, since i held it up
18:55:58 * isis mumbles apologies again
18:56:12 <isis> MarkSmith: please, go ahead
18:56:22 <MarkSmith> Last week Kathy and I assisted with the TB 4.0 release fallout by triaging various tickets.
18:56:32 <MarkSmith> I also answered a few Tor Browser questions on https://tor.stackexchange.com/
18:56:39 <MarkSmith> We fixed #10391 (already merged by Mike -- thanks!)
18:56:53 <MarkSmith> Oops; wrong bug number.
18:57:25 <MarkSmith> We fixed the bug related to "Tor" vs "Tor Browser" in Windows resources.
18:57:32 <MarkSmith> We also spent some time on updater issues, including #13432 and #13512.  And we reviewed boklm's changes for #13324.
18:57:49 <MarkSmith> This week we plan to continue to help with bug triage.
18:57:56 <MarkSmith> We will also look at #13379.  We will need some assistance with the design to make sure security requirements are met.
18:58:33 <MarkSmith> We will probably start by asking mikeperry what he has in mind for the signed MAR files implementation.
18:58:49 <MarkSmith> That's all for us.
18:59:28 <mikeperry> ok. yeah, I guess the plan for that will depend on how the tools work
18:59:38 <mikeperry> and if we can sign them after we generate both full and incremental mars
18:59:51 <mikeperry> because I think that would be the easiest workflow
19:00:03 <mikeperry> build, reproduce, match other builders, then the magic signing key signs them all
19:00:18 <MarkSmith> OK.  I know you have to leave, so we will definitely ping you soon to discuss this more.
19:00:19 <mikeperry> and then they don't match, but at least are signed
19:00:45 <mikeperry> 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 <MarkSmith> "unsign" is an interesting concept given our reproducible build focus.
19:01:37 <boklm> the signature will be included inside the .mar file ?
19:02:53 <MarkSmith> 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 <MarkSmith> Will find out.
19:03:14 <boklm> ok
19:03:43 * boklm can go next
19:04:00 <MarkSmith> (the bug I meant to mention is #13091)
19:04:35 <boklm> 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 <boklm> This week I plan to help with generation of incremental mars for 4.5 alpha.
19:05:15 <boklm> that's it for me
19:05:37 <arthuredelstein> boklm: unrelated question: do we have a windows test machine?
19:06:05 <arthuredelstein> I was thinking it would be nice to run mochitests etc on mingw build to help catch bugs like #13443
19:06:30 <boklm> arthuredelstein: yes, we have a windows test machine, although tests are not running on it yet
19:07:26 <arthuredelstein> Cool. :)
19:08:10 <arthuredelstein> 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 <boklm> arthuredelstein: I will launch it on the 4.0 branch and send you the link
19:09:10 <arthuredelstein> Awesome -- thanks so much
19:09:25 <isis> (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 <isis> not sure if there are other important things which would break
19:10:23 <tjr> I have the minorest of updates.
19:10:29 <tjr> 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 <tjr> I'm going to use that as the base for trying to get the ctamlloc library working on Mac.
19:11:04 <tjr> (that's it)
19:11:16 <isis> tjr: excellent
19:11:42 <MarkSmith> 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 <MarkSmith> someone here, I meant to say
19:12:07 <tjr> Mike indicated that the last release would be the last 32 bit release for Mac in the blog post
19:12:17 <tjr> Barring user feedback that that's a horrible idea
19:13:18 <isis> hmm... the blog post says "very soon"
19:14:06 <isis> 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 <MarkSmith> 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 <MarkSmith> agreed ;)
19:16:08 <tjr> Ah, I was going partly from memory.  Maybe he said it in chat, or maybe I didn't remember right
19:17:23 <isis> thanks for working on that tjr
19:18:26 <isis> boklm, you had finished your reportback, yes? does someone else want to go next?
19:18:26 <tjr> In starts and fits, distracted by shiny things like Directory Authorites :-p
19:18:46 <boklm> isis: yes
19:18:55 * arthuredelstein can go
19:19:06 <isis> tjr: your posts on trying to run a separate network were also interesting! :)
19:19:23 <isis> arthuredelstein: ok
19:19:28 <arthuredelstein> Last week I worked on upgrading my patch for #8641
19:19:46 <arthuredelstein> which simplifies it considerably
19:20:09 <arthuredelstein> 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 <arthuredelstein> And finally I worked on getting mingw debug build working, but as mentioned, no success so far
19:20:57 <arthuredelstein> that's all for me
19:21:39 <arthuredelstein> 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 <boklm> nice :)
19:25:38 <isis> arthuredelstein: wow, the UI for #8641 is awesome looking
19:25:47 <arthuredelstein> thanks :)
19:26:06 <arthuredelstein> Actually, I had a crazy thought of moving it to a drop down from an icon in the URL bar
19:26:24 <arthuredelstein> To the left of the lock icon
19:26:44 <arthuredelstein> I wonder if it would be more intuitive to users then
19:28:16 <isis> 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 <arthuredelstein> Yikes
19:29:03 <MarkSmith> 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 <isis> arthuredelstein: would it be much harder to do it that way?
19:29:19 <arthuredelstein> MarkSmith: That's my concern as well.
19:29:33 <arthuredelstein> isis: I'm not sure, I think it's possible
19:29:47 <MarkSmith> 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 <MarkSmith> (similar to the point isis made about things located near the lock icon).  Hmmm.
19:30:31 <arthuredelstein> It might be interactive in the future, if people want to change exit nodes, for example.
19:32:27 <isis> i will think about this more and try to imagine where i might expect it to be
19:32:52 <arthuredelstein> thanks!
19:33:15 <isis> and thanks for reminding me that my canvas-fingerprinting UI got pretty borked by the ESR31 upgrade... need to make tickets
19:34:03 <isis> ok, who wants to go next?
19:36:53 <isis> did we miss anyone? are there any support desk reports?
19:37:53 <isis> tjr: do you know if there is a ticket for switching to 64-bit mac builds for TBB?
19:38:45 <tjr> Not off the top of my head, let me look...
19:40:03 <tjr> I think it's #10138
19:40:32 <tjr> Note that GeKo's vision for 64 bit builds are using clang, which is harder than using gcc.
19:40:54 <isis> tjr: awesome, thanks! i was searching for "64 osx" and getting zero matches :/
19:41:02 <tjr> 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 <isis> okay, last chance to say something for the meeting, or forever remain in pisces
19:43:01 <isis> #endmeeting
19:43:32 * isis slaps MeetBot with a large fish
19:43:42 <isis> mikeperry: *ahem* ↑↑
19:44:05 <mikeperry> #endmeeting