18:01:53 <mikeperry> #startmeeting tbb-dev
18:01:53 <MeetBot> Meeting started Mon Jun 15 18:01:53 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:53 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:02:17 * n8fr8 n8fr8 and amoghbl1 are here to share orfox updates
18:02:18 <mikeperry> ok, I can go first.
18:02:25 <mikeperry> ah, cool
18:02:59 <mikeperry> well, last week, I rebuilt 4.5.2 and 5.0a2 again to include the OpenSSL update and Tor 0.2.6.9.
18:03:05 <mikeperry> I also filed, tagged, and organized the tickets in the ff38-esr tag. I sent a mail to tbb-dev about this. The tag tbb-5.0a3-essential is the set of things we really need to get done in 5.0a3 by June 30th. The tag tbb-5.0a-highrisk is the set of things we probably should get into an alpha release before
18:03:10 <mikeperry> 5.0-stable. Feel free to add tickets to either list or suggest changes.
18:03:15 <mikeperry> I also broke off a chunk to work on myself over the next couple weeks: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201506
18:03:23 <mikeperry> This week, my plan is do my best to ignore bureaucratic things and work on those tickets. I may also help GK with 4.5.2 and 5.0a2, depending on what needs to be done.
18:04:08 <mikeperry> that is it for me for now
18:04:09 <GeKo> reading my mail from the weekend might help here :) it is encrypted, srsly
18:04:36 <arthuredelstein> What date are we aiming for 5.0-stable?
18:04:50 <GeKo> the thing is the openssl folks broke the ABI in 1.0.1n (thanks to dkg for the hint)
18:05:09 <GeKo> and released openssl 1.0.1o to fix this
18:05:30 <GeKo> arthuredelstein: the date when esr31 is EOL
18:05:32 <mikeperry> *barf*
18:05:36 <GeKo> mid-august
18:06:21 <arthuredelstein> GeKo: Makes sense, thanks
18:06:27 <GeKo> here is what I did:
18:07:05 <GeKo> I worked on the 4.5.2 and 5.0a2 releases
18:07:24 <GeKo> I think I fixed all the toolchain things I defeinitely want to have in 5.0
18:07:37 <GeKo> this includes the remaining bits for #16181 and #16351
18:08:02 <GeKo> then I finished reviewing #16090 and filed all the missing tickets
18:08:30 <GeKo> I wrote a patch for #14387
18:09:10 <GeKo> I am basically done with #16285 and #15910
18:09:29 <GeKo> I need to clean up my patches and post my branches
18:09:56 <GeKo> this week I plan to do
18:10:53 <GeKo> finishing the EME and GMP bits, working on the traacking protection bug
18:11:03 <GeKo> #16282
18:11:28 <GeKo> and I might look at high risk things to get moved forward
18:12:27 <GeKo> I think I should start with #15578 as well
18:12:36 <GeKo> that's it for now
18:14:00 <GeKo> mikeperry: I wonder if I should take #15482 from you given the time I already spent with looking at the Gecko Media Plugins
18:14:12 <GeKo> err #15842
18:14:48 <GeKo> not having GMPs on the radar was basically the reason why Mozilla did not merge the original patch
18:15:27 <mikeperry> ok. what is your plan with that? to have the patch allow them?
18:15:44 <mikeperry> I think ourblock-everything-but-flash patch may also block GMPs?
18:16:13 <GeKo> I think we should start with blocking them as well
18:16:32 <GeKo> especially the adobe cdm is a nightmare
18:17:31 <GeKo> we might want to have a more fine-grained approach in the long run though wrt gmps
18:17:47 <mikeperry> so apparently there is a "keyless" way to do EME to use the same API but without DRM.. I saw a post somewhere recommending that people use/allow that even if they oppose DRM.. whoi knows what that means for us..
18:18:26 <GeKo> yes, I quoted that in the EME bug we have
18:18:29 <mikeperry> ah you mention it
18:19:06 <GeKo> and hsivonen has a point I think but Mozilla does not allow that distinction yet
18:19:44 <GeKo> which is why I'd like to refere cases like that to a more fine-grained approach later
18:19:51 <GeKo> *refer
18:20:28 <mikeperry> ok, so it's either all-or-none at this point then?
18:21:01 <GeKo> yes, that makes the most sense to me at this point and is reflecting the particular mozilla bug iirc
18:21:04 <mikeperry> I guess we should just completely disable it for no
18:21:12 <mikeperry> s/no/now
18:21:39 <GeKo> yes
18:24:12 <mikeperry> #15842 is now yours then
18:24:45 <mikeperry> who wants to go next?
18:25:06 * mcs will give a report
18:25:15 <mcs> Last week, we did some bug triage and code reviews.
18:25:22 <mcs> We worked on our deliverable list for the 2H 2015 contract cycle.
18:25:27 <mcs> We committed our fix for #15145.  Note that if other Tor Launcher fixes need to be made for TB 4.5.next, a branch should be created (don't pick up the #15145 changes).
18:25:41 <mcs> We did some analysis and testing for #13035 and we fixed #16356.
18:25:50 <mcs> Finally, we started to work on #16300 (understanding the feature and implementation with an eye toward how best to insert our URL-bar isolation).
18:25:58 <mcs> This week we will work more on #16300 and then look at other tbb-5.0a3-essential or tbb-5.0a-highrisk issues.
18:26:02 <mcs> That's it.
18:27:00 * arthuredelstein can go
18:27:07 <arthuredelstein> Last week I upstreamed a couple of patches to Mozilla https://bugzilla.mozilla.org/show_bug.cgi?id=967812 and https://bugzilla.mozilla.org/show_bug.cgi?id=629558,
18:27:10 <arthuredelstein> which correspond to #2950 and #2949.
18:27:18 <arthuredelstein> I reviewed #16356 (and committed it to my ESR38 branch)
18:27:24 <arthuredelstein> and I wrote a patch for #15646, which is just about ready.
18:27:32 <arthuredelstein> I also started working on unit tests for #16315.
18:27:44 <arthuredelstein> This week I plan to pick some tbb-5.0a3-essential tickets and work on those.
18:27:59 <arthuredelstein> That's all for me
18:28:18 * n8fr8 amoghbl1 and i are up
18:28:47 <n8fr8> Good progress this week on getting all the bits of network code in the Android/Java layered proxied
18:28:54 <n8fr8> https://dev.guardianproject.info/news/223
18:28:55 <GeKo> arthuredelstein: I have only skimmed the upstreamed patch for #2950 but how does it fix the crash we get on New Identity?
18:29:29 <n8fr8> the hope is that this could be upstreamed into a centralized proxy setting
18:30:07 <arthuredelstein> GeKo: If I understand correctly, that crash had to do with toggling the pref. The upstreamed version is static, so instead of toggling, we just clear the permissions db using `Services.perms.removeAll()`.
18:30:41 <GeKo> hrm... that might help, right
18:30:58 <n8fr8> remaining tasks before our next public alpha are to remove unneeded android permissions, implement the orfox branding, and complete the network leak testing: https://dev.guardianproject.info/projects/orfox-private-browser/issues?fixed_version_id=169&set_filter=1&status_id=o
18:31:02 <n8fr8> anything else, amoghbl1?
18:31:12 <amoghbl1> that's about it n8fr8
18:31:32 <amoghbl1> and the two files differ from the tor-browser repo part
18:31:32 <n8fr8> thanks for the hard work, amoghbl1, and the help TBB team in any reviews you have been, can do
18:31:57 <GeKo> arthuredelstein: still, I am wondering what happens if users are toggling the pref manually. Do they blow their browser away then?
18:32:27 <GeKo> especially if we are assuming that this is bound to a private browsing mode which can be toggled on and off
18:32:54 <arthuredelstein> GeKo: In the upstreamed version, I think nothing happens. They need to restart the browser for a new permissions db to be created. (Sorry for interrupting, n8fr8 and amoghbl1)
18:33:29 <GeKo> ah, okay
18:33:40 <arthuredelstein> GeKo: But I should check this again
18:34:10 <mikeperry> amoghbl1,n8fr8: you probably want to disable https://developer.mozilla.org/en-US/docs/Web/API/Device_Storage_API
18:34:57 <n8fr8> okay, adding a ticket for that
18:35:21 <n8fr8> all in all, i am happy with how few changes we've have to make thus far, so we are a relatively clean set of patches on top of the TB ESR38 branch
18:35:22 <n8fr8> https://github.com/amoghbl1/tor-browser/commits/orfox-tb_GECKO380esr_2015050513_RELBRANCH
18:35:25 <mikeperry> there are a couple other prefs we've noticed
18:36:07 <mikeperry> media.rtsp.enabled needs to be disabled, I think, or it may leak UDP for some video sites
18:36:27 <n8fr8> seems that Device Storage API is FirefoxOS not Android but we'll look into it
18:36:43 <mikeperry> services.push.udp.wakeupEnabled
18:36:46 <n8fr8> yeah, i think RTSP is off, but we'll double check that.
18:37:24 <arthuredelstein> GeKo: #16357
18:37:33 <mikeperry> arthuredelstein: is Services.perms.removeAll synchronous?
18:37:44 <GeKo> yeah, I saw that one
18:39:49 <arthuredelstein> mikeperry: I'm checking that now.
18:40:33 <mikeperry> it looks like the memory removal is synchronous, but the disk one is async
18:41:04 <mikeperry> oh, I am on ff31 branch though
18:42:01 <arthuredelstein> I think you may be right in any case.
18:43:07 <arthuredelstein> There's a weird comment here: https://dxr.mozilla.org/mozilla-central/source/extensions/cookie/nsPermissionManager.cpp#1128
18:43:53 <arthuredelstein> It looks like observers are notified, but before the disk db is wiped. :(
18:44:39 <mikeperry> from that comment, it sounds like the disk version is just some kind of backup..
18:45:27 <arthuredelstein> Of course it's not just a backup, because it gets read when FF starts up.
18:46:31 <arthuredelstein> I guess the important question is whether there is any chance for the old disk db to be read after removeAll is called.
18:46:54 <mikeperry> but perhaps it's using some kind of caching/copy-on-write.. it looks like reads of the permission manager only use the memory db during normal operation
18:47:47 <mikeperry> ex: nsPermissionManager::GetPermissionHashKey
18:50:12 * boklm can go next
18:50:25 <boklm> I made some improvements on the hardening checks we are doing:
18:50:27 <boklm> Changed the tests from Warning to Errors, with lists of files to ignore: https://lists.torproject.org/pipermail/tbb-dev/2015-June/000287.html
18:50:36 <boklm> I added a DEP/ASLR check on Windows binaries (using the script tom posted on #15138)
18:50:44 <boklm> I didn't deploy those changes yet, I'm planning to do it tomorrow.
18:50:55 <boklm> This week I'm planning to fix the acid3 false positive errors we have, and review more Try test results
18:51:01 <boklm> that's all for me.
18:51:10 <GeKo> do we have tickets for all of these files?
18:51:36 <boklm> I don't think we have for all of them
18:52:01 <boklm> I can check and open missing ones
18:52:44 <GeKo> please, if we don't report errors anymore I think we should at least be aware of the underlying issue
18:52:51 <mikeperry> the meek and obfsproxy are due to golang being lame and rejecting hardening
18:52:59 <GeKo> that is true
18:53:19 <mikeperry> however, I am concerned about the stack_canary ones
18:53:22 <GeKo> but i was not aware of the python things for instance
18:53:27 <GeKo> , yes
18:53:58 <GeKo> there is a ticket for the first 5 but the other ones are not covered, yet
18:54:02 <mikeperry> the python ones are a bit concerning too. those are probably a bug in the module build process
18:54:30 <GeKo> #13056
18:54:59 <GeKo> ah, no we have them there too
18:57:19 <boklm> so we need a ticket for DEP/ASLR for the python files ?
18:57:53 <GeKo> yeah, I think so
18:58:23 <GeKo> basisally for all the windows things
18:58:28 <GeKo> *basically
18:59:17 <boklm> ok
19:02:43 <arthuredelstein> mikeperry: In nsPermissionManager, the only place where the disk permissions db is read is in ::Init() { ... ::Read() ...} . I think ::Init() is only called once in a Firefox session (because nsPermissionsManager is a singleton), so it appears we can treat RemoveAll() as synchronous.
19:03:15 <mikeperry> ok, great
19:05:26 <mikeperry> anything else for this week? does anyone have any alterations/suggestions/questions about the tbb-5.0 tagged tickets?
19:07:10 <mikeperry> GeKo: the OpenSSL thing is annoying.. one thing that may be somewhat common is people copying in a custom-compiled or system tor binary into their TBB dir
19:07:37 <GeKo> yeah, that is the only scenario I came up with where we would have issues
19:07:40 <mikeperry> I think it should still use the system openssl in most cases for that though
19:07:53 <mcs> Ticket tagging seems reasonable.  Obviously, anything we can get done sooner is better.
19:08:25 <mcs> Or better said: getting stuff done sooner will lead to a better 5.0 release and less stress for us
19:09:52 <GeKo> mikeperry: I am not sure if that holds on linux, osx and windows
19:10:43 <mikeperry> GeKo: no, I appear to be mistaken. the library paths are set by the script, which means throwing a custom tor into the TBB path may make people sad :/
19:11:03 <GeKo> yes, this is what I meant
19:12:00 <mikeperry> did you already sign the bundles again?
19:12:46 <GeKo> yes, I was in gambling mood yesterday and today :D
19:13:13 <mikeperry> ok, let's just release and make a note on the blog post
19:13:48 <GeKo> you sigs are the only things that are missing in the 4.5.2 and 5.0a2 dirs
19:13:52 <GeKo> *your
19:14:28 <mikeperry> either way, we're updating the tor binary and the openssl binary together, so people will have to accept the update and then go back in and try to break their setup, I think
19:14:38 <mikeperry> unless they also edited the start-tor-browser scripts..
19:15:00 <GeKo> yes
19:16:47 <mikeperry> so where are you in the release process? right before the .htaccess and copy to dist?
19:17:37 <GeKo> yes
19:18:12 <mikeperry> ok, I will add my sigs and release it later today/this evening
19:18:37 <teor> mikeperry: when I was testing a custom tor in TBB 4.0 and 4.5 on OS X, I modified the tor path in the script, not the tor binary. It worked fine.
19:18:53 <teor> Maybe we could recommend people do that rather than moving binaries.
19:19:00 <GeKo> that should not be a problem
19:19:07 <GeKo> yeah
19:19:12 <mikeperry> actually, unclear, because we also set LD_LIBRARY_PATH
19:19:27 <mikeperry> so if you don't also edit that, your new tor path will use our bad openssl lib, and probably crash
19:19:41 <GeKo> hm...
19:22:46 <mikeperry> so teor's tbb will probably update and then stop working :/
19:22:59 <mikeperry> because we did not update start-tor-browser in this release
19:23:44 <mikeperry> I think nickm is in a similar situation
19:24:09 <GeKo> man, this sucks
19:24:20 <mikeperry> (I remember him telluing me about copying alpha tor binaries into his path
19:24:22 <mikeperry> )
19:26:39 <nickm> symlinking
19:26:42 <nickm> but yeah
19:26:51 <nickm> and don't worry; we know what we're getting into
19:27:08 <nickm> "No user-serviceable parts inside"
19:27:43 <mcs> I guess a question for the Tor Browser team would be "How many people will this impact?"
19:27:51 <mcs> (impossible to know)
19:28:11 <mikeperry> yeah, I think the types of people it will impact is still limited to hackers and developers
19:28:25 <mcs> So, in other words, people who are used to pain?
19:28:44 <nickm> people who understand "you broke it, you can keep both pieces"
19:31:28 <mikeperry> ok. I think in the interst of saving GeKo's time and sanity, we just go with this release as-is then?
19:32:02 <mikeperry> we should file  bug for this though, so it shows up in the 4.5.3 changelog
19:32:26 <mikeperry> "hey, we fixed that thing we broke on purpose in the last release!" :)
19:32:30 <GeKo> yes, filing the bug is a good idea
19:32:45 <GeKo> haha
19:33:38 <mcs> Will the breakage be obvious, e.g., tor crashes on startup every time?  Or do we know?
19:34:02 <mcs> (if it is obvious, and we mention it in our release notes, it seems OK to me)
19:34:36 <GeKo> dunno actually.
19:34:55 <teor> I completely agree: "don't do that, unless you enjoy re-downloading Tor Browser when it breaks"
19:35:43 <teor> mcs: oh yeah, breakage is obvious: "Tor failed to launch" etc
19:35:59 <mcs> OK.  Ship it?
19:36:38 <teor> (Which is exactly why I *stopped* screwing with TBB internals)
19:36:56 <GeKo> I think so.
19:37:02 <mikeperry> I am trying it now.
19:37:10 <mikeperry> the tor binary seemed to run "ok" with the bad openssl
19:37:31 <GeKo> I a actually not convinced that we break system tor usage
19:37:36 <GeKo> *am
19:38:50 <mikeperry> strange
19:38:51 <teor> Replacing the embedded tor with /opt/bin/tor from macports works fine
19:39:02 <mikeperry> yeah, it worlks fine for me too
19:39:13 <mikeperry> maybe we don't use the hmac that they broke?
19:39:20 <teor> But macports tor uses macports ssl
19:39:51 <mikeperry> I just put the tbb 4.5.1 tor binary inside a tbb 4.5.2 dir, and it still worked..
19:40:35 <mikeperry> and it said "tor 0.2.6.7 with openssl 1.0.1n" so it did use the "incompatible openssl
19:41:01 <teor> I tried it with 0.2.7.1-alpha compiled using afl-fuzz, and it still worked
19:41:12 <teor> It appears very hard to end up with two pieces
19:41:23 <GeKo> even better :)
19:41:43 <GeKo> and in two weeks the next Tor Browser is coming fixing this issue
19:44:36 <mikeperry> I think we must not be using the hmac function in quwstion externally to openssl
19:44:57 <mikeperry> in question too
19:48:09 <teor> I got it to hang once, force quit, then "tor has unexpectedly exited"on relaunch, but the third time was fine
19:48:26 <teor> Tor v0.2.7.1-alpha-dev (git-ef2b2ceb9cc7fb6a) running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.1.0-dev and Zlib 1.2.8.
19:48:31 <mikeperry> hrmm... might be some weird flavor of memory corruption then :/
19:48:59 <teor> OpenSSL? Memory corruption?
19:50:16 <teor> Never!
19:51:50 <teor> Yeah, or it could be discoveryd or my router playing up. My machine isn't playing nicely tonight.
19:53:25 <mikeperry> we use HMAC(), not HMAC_CTX_init*(). the bug is in how HMAC_CTX was changed, which we do not use externally to openssl in tor
19:55:39 <mikeperry> so I think we're actually not affected
19:55:57 <mikeperry> the 0.2.7.1 crash must have been something else, teor
19:56:06 <teor> I agree
19:57:25 <mikeperry> ok, I think we can end this meeting then. *phew* that was a close call
19:58:01 <mikeperry> sorry for the long meeting everyone, but at least we got to the bottom of that
19:58:46 <mikeperry> GeKo: I will pick up where you left off and finish the release
19:58:58 <mikeperry> thanks everyone!
19:59:03 <mikeperry> #endmeeting tbb-dev