17:59:43 <mikeperry> #startmeeting tbb-dev
17:59:43 <MeetBot> Meeting started Mon Jun 22 17:59:43 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:51 <mikeperry> ok, let's get started!
18:00:07 <mikeperry> Last week, I helped with getting 4.5.2 and 5.0a2 out the door, and then began working on tickets in https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201506. I think all of my tbb-5.0a3-essential tickets are either solved, or very close (just a couple of prefs that need to be set).
18:00:15 <mikeperry> Most of my time was spent on #16222. I found some things that could use another set of eyes. See https://trac.torproject.org/projects/tor/ticket/16222#comment:4. Right now, my estimation is that everything serious can be preffed off. Related, #16334 also seems to be a non-issue. Since a lot of networking stuff is wrapped up in WebRTC, I don't think #14836 is safe at this point either.
18:00:22 <mikeperry> I also wrote a fix for #16005, and looked into #16254. I think #16254 is good to go with the pref changes mcs and I listed in that ticket.
18:00:27 <mikeperry> This week, my plan is to finish #15514 and #16110. It looks like I won't get #14952 done by Thursday. :/
18:00:35 <mikeperry> For general release things, we're still aiming for Tuesday June 30th for our first FF38-based release. This means we should aim to have everything reviewed and merged by this Thursday at the latest. Please tag stuff you plan to review in https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TorBrowserTeam201506R with your own review tag, so we can make sure everything is covered in tim
18:00:42 <mikeperry> e for merge.
18:00:43 <mikeperry> At the end of the meeting, we can spend some time coordinating and ensuring everything in https://trac.torproject.org/projects/tor/query?keywords=~tbb-5.0a3-essential&status=!closed is covered, and getting agreement on what items of https://trac.torproject.org/projects/tor/query?keywords=~tbb-5.0a-highrisk&status=!closed we want to include.
18:00:55 <mikeperry> that's it for me for now
18:02:27 <mikeperry> dag, where is the zwieblebot? no ticket titles :/
18:03:39 <GeKo> I think we can HTTP/2 and SPDY just pref off for the alpha for now
18:03:46 <mikeperry> yeah
18:04:10 <GeKo> here is what I did:
18:04:42 <GeKo> I triaged the SVG patch related crash (#16397)
18:05:21 <GeKo> then I worked on all the remaining build things and my tbb-essential bugs
18:05:34 <GeKo> as far as I can see we are in good shape there now
18:05:42 <GeKo> I did (start) some reviews: #16315, #15646, #16300
18:06:19 <GeKo> I fought with the releases 4.5.2 and 5.0a2: for some reasons some files were 0 bytes in size for 4.5.2
18:06:25 <GeKo> I had to re-sync stuff
18:06:41 <mikeperry> yeah I don't know why that happened :/
18:07:05 <GeKo> this week I plan to continue doing reviews and work further on #15842
18:07:20 <mikeperry> next time I will check the shasums after trasnferring them, though that won't catch windows file corruption
18:07:25 <mikeperry> (because of the sigs)
18:07:32 <GeKo> yes
18:07:45 <mcs> maybe also check for files with size == 0:)
18:07:53 <GeKo> indeed :)
18:07:54 <mcs> == 0
18:08:31 <mikeperry> yeah. though I can sense that whatever bug caused that is just waiting to give us partial downloads next time, instead of 0 size files..
18:08:40 <mcs> right
18:08:45 <mikeperry> I can also import the package signing public key and do a for loop to verify the per-file sigs
18:09:01 <GeKo> I am inclined to just move #15482 to ff45-esr as we strictly speaking don't need it for esr38 due to the handling of the GMPs we do
18:09:22 <GeKo> that's it for me
18:09:48 <GeKo> err #15842
18:09:49 <mikeperry> #15482? the tor patch?
18:09:56 <GeKo> nah, typo
18:09:56 <mikeperry> ok
18:10:37 <mikeperry> so we block all GMPs from even loading into the process space, yes?
18:10:45 <mikeperry> via the plugin blocking patch?
18:12:23 <GeKo> well, the GMPs are not system-wide and we block them quite thoroughly from being downloaded in the first place.
18:12:30 <mikeperry> ok
18:13:02 <GeKo> and there is no EME as we compile it out
18:13:11 <GeKo> (or better don't compile it in)
18:13:49 <mikeperry> I saw the data url hack. I am wondering if we should do that for our 127.0.0.1 update url hack for torbutton + tor launcher instead of 127.0.0.1. that one upset bobnomnom/random SSH socks proxy users
18:14:04 <GeKo> I tried that actually but it does not work
18:14:25 <GeKo> the problem is it seems that we need an https:// scheme
18:14:44 <mikeperry> ah, ok
18:14:55 <GeKo> I have not tracked the exact reason down but the extensions won't get installed with this update hack
18:15:12 <mikeperry> ok, at least we tried it. nice
18:15:25 <GeKo> yeah, I has the same idea it seems :)
18:15:27 <GeKo> *had
18:19:31 <mikeperry> ok, who wants to go next?
18:19:53 * mcs can go
18:20:02 <mcs> Last week, Kathy and I spent most of our time on #16300 (BroadcastChannel API) and #16397 (new SVG-related crash).
18:20:08 <mcs> We posted patches for both tickets (ready for review).
18:20:14 <mcs> We also did some bug triage and reviewed several ESR 38 patches.
18:20:19 <mcs> As for this week, earlier today GeKo asked us to help with investigation of open issues for #16222 Review networking code for Firefox 38).
18:20:28 <mcs> And then we will look at other remaining tbb-5.0a3-essential or tbb-5.0a-highrisk issues.
18:20:32 <mcs> If time permits, we will develop some automated tests for #16300.
18:20:41 <mcs> Of course we are prepared to be interrupted if any last minute TB 5.0a3 issues come up.
18:20:44 <mcs> That's all for us.
18:21:40 * arthuredelstein can go
18:21:46 <arthuredelstein> Last week I thought I had completed a patch for #15646, although GeKo found a problem with it that needs work.
18:21:50 <arthuredelstein> I also wrote a patch for #16315 that seems to be OK.
18:22:01 <arthuredelstein> I applied some patches you all wrote and I created a new branch for #15196, https://github.com/arthuredelstein/tor-browser/commits/tb_GECKO380esr_2015050513_RELBRANCH+2, that squashes some of our mozconfig* and canvas-fingerprinting commits.
18:22:11 <arthuredelstein> I started working on regression tests for #15703 -- I'm optimistic that mediasource: URIs are mostly already isolated, because they share a lot of code with blob URIs.
18:22:16 <arthuredelstein> I did a little work on https://bugzilla.mozilla.org/show_bug.cgi?id=1173199, and some investigation of #16327.
18:22:32 <arthuredelstein> This week I hope to finish up #15646 for real, and #15703, and look at any other ff38-esr patches that seem useful. (I'm open to suggestions.)
18:22:49 <arthuredelstein> That's it for me
18:23:28 * n8fr8 and amoghbl1 can go
18:23:35 <mikeperry> GeKo: so what is your estimation about what to do for #15646 if issues remain? by thursday? should we take the patch as it is then, and iterate later, or wait entirely?
18:23:44 * n8fr8 once mikeperry is done!
18:24:54 <GeKo> mikeperry: I think we should take what we can get and iterate later
18:25:13 <arthuredelstein> Re #15646 my plan now is to test on Windows, OSX and linux with different keyboards. Apparently something is not cross-platform about my code.
18:25:13 <mikeperry> same question for #13670?
18:25:52 <GeKo> I think we should revert your changes and then we are good, no?
18:26:21 <arthuredelstein> It probably makes sense for me to go over mcs's suggestions on #13670 as well.
18:27:12 <GeKo> yes, they sound like things that need to get improved but don't need that much work I guess
18:27:19 <mikeperry> oh hrmm.. making the isolation key be the full URI seems non-ideal.. I could make the key into a URI by keeping the scheme only, I guess?
18:27:24 <mikeperry> or arthur could?
18:27:41 <mikeperry> has that patch been rebased?
18:28:10 <arthuredelstein> It has been rebased, yes.
18:28:29 <GeKo> yeah, if you could have a look at it, arthur, that would be good
18:28:52 <arthuredelstein> Yes, I'll try to have a fixup by Wed or so.
18:29:03 <mikeperry> IIRC, the isolation key also affected the OCSP cache
18:29:17 <mikeperry> which means way more OCSP requests if we isolate by full URI spec
18:29:25 <mikeperry> and way more circuits
18:29:31 <arthuredelstein> mikeperry: I think you're right that we should be using the domain, and not the full URI.
18:29:39 <arthuredelstein> That was mistake on my part.
18:29:50 <arthuredelstein> So whatever final version we have this week should include limiting by domain.
18:29:57 <GeKo> ok, nice
18:30:34 <n8fr8> alright, so quick update on the Orfox front:
18:31:06 <n8fr8> we've mostly been testing this last week, looking out for leaks at various levels in the Android java code, and i think we are in good shape
18:31:07 <n8fr8> https://github.com/guardianproject/tor-browser/tree/orfox-tb_GECKO380esr_2015050513_RELBRANCH
18:31:29 <n8fr8> our main problems now are very mobile specific which are disabling all the app permissions we don't want gracefully
18:31:36 <n8fr8> (like camera, gps, wifi managemenet, etc)
18:32:00 <n8fr8> and figuring out what to do about the user-agent
18:32:12 <n8fr8> currently we used the Tor-browser standard user-agent which creates a pretty bad user experience
18:32:18 <n8fr8> since you will always get the full blown desktop sites
18:32:37 <n8fr8> currently we are considering a "mobile compatibility mode" option that is off by default
18:33:03 <GeKo> what does that mean?
18:33:14 <n8fr8> it means putting "Android" in the user-agent instead of Windows NT
18:33:37 <n8fr8> which reduces you to just the Orfox users uniqueness vs all of tor browser users
18:34:06 <GeKo> ok
18:35:06 <n8fr8> otherwise, the app is stable, working well, building on our build box, and ready for a public alpha in the next few days
18:35:44 <mikeperry> n8fr8: I noticed some androidy stuff during my FF38 network audit that may apply to you.. but it may also be B2G/FxOS stuff
18:35:50 <n8fr8> anything else, amoghbl1? project tracker is here for those interested: https://dev.guardianproject.info/projects/orfox-private-browser/roadmap
18:35:53 <mikeperry> there is some Roku screen sharing capability
18:35:59 <mikeperry> in ./toolkit/modules/secondscreen/RokuApp.jsm
18:36:06 <amoghbl1> we've disabled the screen sharing stuff mikeperry
18:36:25 <amoghbl1> But there's a lot of stuff in there that still needs to be removed
18:36:30 <mikeperry> ./toolkit/modules/Sntp.jsm also may apply
18:37:12 <n8fr8> okay. that also reminds we, that we are still figuring out how to bundle in HTTPSEverywhere for Android and other extensions
18:37:21 <arthuredelstein> FWIW, https://github.com/arthuredelstein/tor-browser/commits/tb_GECKO380esr_2015050513_RELBRANCH is a bit out of date and we are now working from https://github.com/arthuredelstein/tor-browser/commits/tb_GECKO380esr_2015050513_RELBRANCH+2 . It shouldn't be fairly trivial to rebase to, I think.
18:37:36 <n8fr8> yes, i'll make sure we do that before the release
18:37:37 <arthuredelstein> s/shoudn't/should
18:38:21 <n8fr8> anything else, amoghbl1?
18:38:30 <mikeperry> there's also ./netwerk/base/src/Tickler.cpp which probably isn't a huge problem, but is a leak.. and as I previously mentioned RTSP (media.rtsp.enabled)
18:38:52 <amoghbl1> I think that's it, permissions are the scary part for now, work on that is currently underway
18:39:17 <amoghbl1> rtsp has been disabled mikeperry
18:39:44 <amoghbl1> as well as udp push service wakeup
18:40:22 <mikeperry> do you include torbutton at all?
18:40:51 <GeKo> n8fr8: what are your orfox internal updater plans?
18:40:59 <GeKo> I don't find any on the roadmap
18:41:10 <mikeperry> it still has some code that handles things like circuit isolation, window.name, and probably one or two other things
18:41:30 <mikeperry> and new identity, of course
18:41:52 <n8fr8> doing internal updates on Android isn't really practical. we have to rely on fdroid or google play for updates.
18:41:55 <mikeperry> probably not needed for a alpha/pre-release, but worth considering in the longer term
18:42:04 <amoghbl1> Haven't worked out how to include a plugin into the apk mikeperry, once that's done, I think that will be possible
18:42:16 <mikeperry> yeah, agreed. you want to stick with the f-droid/google play updater
18:42:23 <amoghbl1> I agree with n8fr8 about the internal updates part
18:42:40 <GeKo> why do you have to do that?
18:43:43 <n8fr8> we don't have to do it, but we've put a lot of effort into working on the entire f-droid system as a trustworthy app repository mechanism
18:43:46 <mikeperry> having updates come from somewhere other than the app store you got the app is just weird for android.. it's also a bunch of complexity you don't want.
18:43:49 <n8fr8> and repro builds, etc
18:44:09 <mikeperry> and yeah, making f-droid be secure is the way to go instead
18:44:32 <n8fr8> we have a .onion app repository for instance: https://guardianproject.info/fdroid/repo/
18:44:42 <GeKo> ok, sounds reasonable then
18:44:43 <amoghbl1> I don't think fennec supports it at all infact, need to recheck that though
18:44:43 <n8fr8> http://bdf2wcxujkg6qqff.onion/fdroid/repo?fingerprint=B7C2EEFD8DAC7806AF67DFCD92EB18126BC08312A7F2D6F3862E46013C7A6135
18:45:02 <n8fr8> A good question, and something we need to document more
18:45:07 <GeKo> amoghbl1: it support it last time I tried
18:45:11 <n8fr8> especially in the realm of "How is Orfox different than Tor Browser"
18:45:14 <GeKo> at least my nightlies got updates
18:45:22 <_hc> plus, I think internal updating is not allowed by Google Play's terms of service
18:45:35 <GeKo> yeah, thanks Google
18:46:02 * GeKo shuts up before he starts ranting too much
18:46:13 <mikeperry> the initial download is the weakest link in the whole android app store model anyway. once you get an app, the android OS pins the app signing key to the first one it found
18:46:35 <mikeperry> which is presumably controlled by you and no one else, so after first download, Google can't feed you malicious updates anyway
18:47:08 <mikeperry> (sorry for the ambiguous overuse of 'you' in that sentence)
18:48:28 <mikeperry> f-droid is even better, because the first download is via pinned https and/or an onion URL, and doesn't have any unique identifiers to target specific users
18:48:39 <GeKo> nice
18:49:48 <mikeperry> ok, so that sounds good. thanks amoghbl1+n8fr8!
18:50:00 <n8fr8> ty!
18:50:05 <amoghbl1> thanks!
18:50:18 * boklm can go next
18:50:32 <boklm> I added new commits from tb_GECKO380esr_2015050513_RELBRANCH+1 to my splitted branches repo
18:50:39 <boklm> I made some small improvements to the tbgit script, and looked at some of the tests results to disable failing tests
18:50:42 <boklm> This week I'm planning to continue on that
18:50:43 <boklm> that's all for me
18:51:29 <mikeperry> ah. right, we need to decide if we want to start using the split branches for the 5.0a3 release
18:52:06 <mikeperry> I failed to look into that closely enough to make that call yet, though :/
18:53:48 <mikeperry> do we want to wait until after things have solidified a bit more? or try to do it for this release? I am a little nervous about more changes to our build+release process right now
18:54:02 <boklm> If we don't use it yet for the release, I can still maintain that repo in parrallel to run the tests
18:54:13 <GeKo> yes, let us leave it for now
18:54:30 <_hc> mikeperry: there is another layer in fdroid as well: signed metadata.  the signing keys from the F-droid.org and guardianproject.info repos are built into the client
18:54:32 <GeKo> as it is
18:54:54 <_hc> both of those repos use a fully offline metadata signing process
18:55:25 <mikeperry> _hc: awesome
18:55:54 <GeKo> while we are talking about the branches, have the disk space issues been sorted out?
18:56:30 <GeKo> I'd like to have arthur's branch on tpo infrastructure to point our gitian versions files to it
18:56:33 <mikeperry> no. was it disk space? all I know is that I got this error:
18:56:34 <mikeperry> error: inflate: data stream error (invalid distance too far back)
18:56:34 <mikeperry> fatal: pack has bad object at offset 66502595: inflate returned -3
18:56:34 <mikeperry> error: pack-objects died of signal 13
18:56:34 <mikeperry> error: failed to push some refs to 'ssh://git@git-rw.torproject.org/user/mikeperry/tor-browser.git'
18:56:51 <GeKo> ah, I assumed that reading your comment
18:56:55 <mikeperry> I got that while trying to push my bug16005 branch
18:57:28 <mikeperry> I am not sure if it is because my repo got messed up somehow, or if it will happen to anyone
18:57:40 <mikeperry> I hadn't yet pushed any ff38 stuff to my remote, so it was a very big push
18:58:45 <GeKo> ok, then what about tor-browser-38.1.0esr.5.0-x-1 with arthur's rebased branch?
18:59:18 <GeKo> tor-browser-38.1.0esr-5.x-1
18:59:23 <GeKo> or something
18:59:28 <mikeperry> pushing that to the main tor-browser.git you mean?
18:59:46 <GeKo> yes,that is actually the missing piece to get all the reamining tor-browser-bundle changes merged
19:00:11 <GeKo> as I want to point at least the nightly build to an official branch
19:00:34 <mikeperry> I suppose I should try that right now
19:01:16 <mikeperry> are we ready to start calling 56022741b567226a3793f7d88abb56ecdcbfa502 from arthur/tb_GECKO380esr_2015050513_RELBRANCH+2 the new tor-browser/tor-browser-38.1.0esr-5.x-1?
19:03:14 <mikeperry> I am about to push that. what could go wrong?
19:03:29 <mcs> Go for it.
19:03:35 <GeKo> yes
19:04:20 <mikeperry> Writing objects:   5% (32614/644593), 7.49 MiB | 294.00 KiB/s
19:04:23 <mikeperry> this may take a while
19:06:40 <mcs> If we are done with the status and 'start a large git push' portion of the meeting, I have a question about #16222 (networking code).
19:06:46 <mikeperry> anything else while we wait for that?
19:06:49 <mikeperry> heh
19:07:05 <mcs> What should Kathy and I look at?  Maybe the WebIDE issue?
19:07:39 <mcs> Or are you more worried about WepappRT?
19:07:56 <mikeperry> I think I am not very worried about WebappRT.
19:08:01 <mcs> OK
19:08:42 <mikeperry> WebIDE is definitely bad news for several reasons. I know I want it off. the main question there is do we also want to set those other devtools prefs, too? did any of this stuff creep into the normal webconsole debugger?
19:09:06 <mcs> OK.  I think we will take a look at WebIDE unless you or GeKo are going to do so.
19:10:24 <GeKo> mikeperry: if you have ideas for #16268 that might be helpful
19:10:37 <mikeperry> ok.  if  the mozilla build processis easy for you to follow, could you also spot-check if toolkit/modules/secondscreen/SimpleServiceDiscovery.jsm is compiled in on the desktop? most of the moz.build files were easy for me to check, but that one is weird
19:11:25 <mcs> mikeperry: yes, we will check (even though the build process is not easy for us to follow either)
19:12:28 <GeKo> then I was thinking whether we should try to get a last-minute merge of #12523 going for the alpha. I am quite tempted here.
19:12:43 <GeKo> I definitely don't want to ship that in a stable without an alpha first
19:12:53 <GeKo> and having it for 5.0 might be worthwhile
19:14:16 <mikeperry> re #16268: I don't recall the &amp; issue. I can look at that more closely and see if anything comes to mind later..
19:14:56 <arthuredelstein> I can try and look at #12523 this week, but of course we could add it in a later 5.0-alpha.
19:15:07 <GeKo> if there is one at all
19:15:15 <mikeperry> shit. I got the same error for my tor-browser push. GeKo you may need to try that, and if it fails for you, we'll have to bug weasel
19:15:28 <GeKo> ok, doing that now
19:16:34 <GeKo> arthuredelstein: well, I think they keyboard and isolation stuff should have higher prio I think
19:16:37 <GeKo> *the
19:16:57 <arthuredelstein> GeKo: yes
19:17:42 <mikeperry> hrmm.. I think #12523 may need more time to bake. the last thing we need is wondering if weird crashes were due to our build process, one of our patches, or this thing, and since it has no pref, we can't easily spot check
19:17:48 <GeKo> and I think even if we get the rebase going I'd like to have a test run with a nightly first, so the time might not be enough
19:17:59 <GeKo> yes, exactly :/
19:18:25 <arthuredelstein> good point. I'll leave it for later then.
19:20:15 <mikeperry> wrt git issues: worst case, I also have a github account.. I can push a signed 38 branch to a repo there and we can build from that :/
19:20:16 <mcs> r.e. #16268, I just found the ticket where this came up before.  See: https://trac.torproject.org/projects/tor/ticket/11699#comment:8
19:20:40 <mcs> It sounds like something had to be done on the Transifex side of things.
19:20:49 <boklm> mikeperry: maybe "git fsck" can tell you if something is wrong with your local repo
19:21:37 <mikeperry> boklm: thanks. trying that now
19:23:51 <mikeperry> Phoul1: I just assigned #16268 to you, on the assumption that it is a similar issue to mcs's https://trac.torproject.org/projects/tor/ticket/11699#comment:8
19:24:14 <mikeperry> boklm: aha, git fsck has found similar-sounding errors. I wonder if it will fix them
19:27:47 <mikeperry> ok. anything else? it looks to me like we're in good shape for tbb-5.0a3-essential, modulo some code reviews
19:28:12 <GeKo> just a personal announcement for planning
19:28:33 <GeKo> I plan to be on vacation from July 4 to July 18
19:28:53 <GeKo> I might be able to get something done in the first week if hell is freezing over
19:29:02 <GeKo> but that won't even help for the second week
19:29:48 <mikeperry> I think that should be a quiet time, unless openssl explodes again
19:30:00 <GeKo> heh
19:30:01 <mcs> Probably bad timing, but Kathy and I will be out the week of July 13th (no computers, no Internet).  So some overlap w/GeKo's vacation.
19:30:02 <mikeperry> and if it does, I guess we wait, since we still have onl yone window signing key
19:31:43 <arthuredelstein> mikeperry: I think if git fsck is finding corrupted objects in your local repo, you probably need to fetch a new copy of the branch.
19:31:56 <mikeperry> oh crap. that reminds me that I will be flying to PETS during our meeting on next Monday :(
19:32:05 <GeKo> mikeperry: which reminds me that 5.0 stable is to be released during CCCamp :)
19:32:23 <mikeperry> I don't know if the plane will have wifi
19:32:59 <mcs> Would it help to move next week's meeting to Tuesday?
19:33:56 <mikeperry> I already decided against CCCamp this year, I think, mostly due to intertia. but I guess now also for tha reason
19:34:17 <boklm> This might help to recover corrupted objects: https://github.com/git/git/blob/master/Documentation/howto/recover-corrupted-blob-object.txt
19:34:31 <boklm> but fetching a new copy might be easier
19:34:34 <mikeperry> I am not sure. I suppose it is probably a good idea to move the meeting? what do you think GeKo?
19:34:51 <GeKo> I am fine either way
19:35:34 <mikeperry> If everything is exploding, I am not sure a meeting will help.. the builds should be done by then, or we'll be releasing much later in the week
19:37:11 <GeKo> I can run the meeting if that's easier for you
19:37:47 <mikeperry> I think that will be the best plan. if the flight has wifi, I will try to join
19:40:09 <mikeperry> ok, are we finally ready to bring this long meeting to a close then? :)
19:41:23 <mikeperry> (I will take my git problems offline, and either re-clone or try to repair my repo. it does sound specific to me)
19:42:27 <mikeperry> ok, I declare this meeting over. thanks everyone!
19:42:35 <mikeperry> #endmeeting *baf*