18:00:57 <mikeperry> #startmeeting tbb
18:00:57 <MeetBot> Meeting started Mon Sep 22 18:00:57 2014 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:57 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:24 * isis is listening in on the meeting
18:02:17 <mikeperry> last week I finished the review of the Firefox networking system calls. notes are at https://gitweb.torproject.org/tor-browser-spec.git/blob/HEAD:/audits/FF31_NETWORK_AUDIT
18:03:01 <mikeperry> I have 4 patches for defnese in depth for some codepaths that *looked* like they shouldn't happen in the main browser build, but because of tangles of function pointers, I wasn't absolutely sure
18:03:24 <mikeperry> I need to run the unit tests against them to see what happens
18:03:51 <mikeperry> I also need to understand how gstreamer is used still, to make sure it isn't possible to do any network activity
18:04:26 <GeKo> mikeperry: XXX: Our rebased patch has a weird chunk in the wrong place here! <- should be fixed now
18:04:49 <GeKo> arthuredelstein fixed that in one of the last commits
18:04:51 <mikeperry> arthuredelstein: what is the unittest status of your branch? if I put my patches on top of it, can I run the tests locally?
18:04:56 <mikeperry> ah, cool
18:06:14 <mikeperry> I am thinking we should probably rebase and squash arthur's 12620 branch on top of 31.1.0. it is getting a bit messy
18:06:22 <arthuredelstein> mikeperry: The unittests I have added so far are in the tbb-tests directory. You can run them by `./mach mochitest-plain or ./mach mochitest-browser`
18:06:56 <arthuredelstein> I agree regarding squashing.
18:08:21 <arthuredelstein> (and rebasing). I can do that today and then maybe we should move it to git.torproject.org?
18:08:30 <mikeperry> yeah
18:11:45 <mikeperry> this week we should also aim for releasing 4.0a3, but we can discuss that after everyone has a chance to talk about their activities/plans. It looks like GeKo updated the changelog already at: https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/refs/heads/master:/Bundle-Data/Docs/ChangeLog.txt, so now might be a good time to look at that while you wait, in case you have any suggestions as to what else should be included
18:12:09 <mikeperry> that's it for me
18:12:46 <GeKo> here is what I did:
18:13:35 <GeKo> I finished my esr31 gitian work: I have clean-up all the tor-browser patches and the gitian descriptor patches we need
18:13:52 <hellais> I have a question, where were the PT addresses placed before this file existed: https://gitweb.torproject.org/builders/tor-browser-bundle.git/history/HEAD:/Bundle-Data/PTConfigs/bridge_prefs.js?
18:13:55 <GeKo> and tested things on different machines. so far it looks quite good.
18:14:20 <GeKo> then I prepared all I could prepare for 4.0a3
18:14:59 <GeKo> I started to look at #13186 and the resource timing ticket and am currently writing tests for them
18:15:52 <GeKo> #13024 is the one
18:16:51 <GeKo> and I thought a bit about #10804 and how we might solve it properly.
18:17:16 <GeKo> this week I plan to finish the tests I am working on and start working on other important ESR 31 things.
18:17:20 <GeKo> that's it.
18:18:33 <GeKo> oh and I rebased and tested the fix for #10716
18:18:49 <MarkSmith> For #10804, does "solve it properly" mean fixing something inside the Mozilla code or fixing Torbutton/Tor Launcher/HTTPS Everywhere to work around the problem?
18:19:20 <arthuredelstein> mikeperry: We may want to include #12998 in 4.0a3
18:19:48 <GeKo> MarkSmith: given the headaches for the support and given our time constraint for getting this into the next release the latter
18:20:00 <MarkSmith> OK.
18:22:50 <mikeperry> do we like that workaround in #10804 that asmith posted? (basically relocating the crazy event thread hack)
18:25:21 <MarkSmith> I am not sure since brade and I have never found a way to reproduce the issue.
18:25:23 <GeKo> I am not sure yet
18:25:32 <MarkSmith> GeKo: ?
18:25:45 <MarkSmith> At least we agree on un-sureness ;)
18:25:55 <GeKo> indeed :)
18:26:24 <GeKo> what about fixing #9693 and using that one?
18:27:45 <GeKo> and I tend to agree that I actually hijacked #10804 by duplicating all the other things over and that we actually have two bugs here.
18:28:21 <mikeperry> we can do that, but if there is any other https activity (like the updater or update check for Torbutton) we'll still have a race..
18:29:40 <GeKo> the update check to Torbutton goes to https://127.0.0.1
18:29:47 <GeKo> do that's nothing to worry about
18:29:52 <GeKo> *so
18:30:01 <mikeperry> no, I meant the versioncheck
18:30:13 <GeKo> I see
18:30:25 <mikeperry> for RecommendedTBBVersions
18:30:33 <MarkSmith> I agree there may still be a race, but this problem may be affecting enough people that reducing the frequency would be a big win (imperfect fix may be better than doing nothing).
18:30:34 <mikeperry> happens a bit later in startup though, so may be ok?
18:31:38 <GeKo> I am a bit worried to have that we allow our ugly workaround to get called on start-up where all sorts of crazy things are happening
18:31:56 <GeKo> like resizing the window and such
18:32:52 <MarkSmith> Does HTTPS Everywhere need to connect to check.t.o on startup?  I don't know the history of that code.
18:33:14 <mikeperry> not for TBB, no. it's for testing if a user has Tor installed when they are running in normal firefox
18:33:57 <mikeperry> we can fix that, but we need to ask EFF nicely to give us a pointfix with the fix in it.
18:34:21 <mikeperry> I also tried to completely disable all of that code unless the observatory was enabled, but apparently that lead to Firefox crashes
18:35:18 <GeKo> I am escpeially worried about https://bugzilla.mozilla.org/show_bug.cgi?id=582613
18:35:44 <GeKo> where the Firebug people used suppressEventHandling and that caused hangs during resize events
18:36:29 <GeKo> this is avoided in our current code I think but I am not sure wrt to the proposed patch
18:37:08 <GeKo> that's why m HTTPS-E idea
18:37:11 <GeKo> *my
18:38:01 <GeKo> but yeah, that does not buy is anything if there is other code doing TLS stuff early
18:38:07 <GeKo> *us
18:40:37 <mikeperry> ok, well I will be meeting with EFF and Mozilla tomorrow. I can see if we can sneak in some kind of pref patch for this into a point release
18:42:32 <mikeperry> and for extra fun, it looks like there will be a chemspill firefox release this week, so we may have to rebuild 3.6.x as well
18:43:01 <mikeperry> hopefully they will pick up this fix for FF24esr. I am not sure how they'll decide to handle this yet
18:43:47 <GeKo> ugh
18:44:41 <mikeperry> ah, just got the mail. they will be updating FF24 for us
18:45:36 <mikeperry> ok, well, who's next?
18:46:19 * boklm can be next
18:47:00 <boklm> So last week I made a few changes to the update responses script for #13047
18:47:31 <boklm> And I added a test that loads a page that plays videos in different formats, and check for any network leak using mbox
18:48:15 <boklm> This week I plan to write some documentation to explain how to add new test pages to our test suite
18:48:38 <boklm> and improve the update responses script so it can generate incremental .mar files
18:49:11 <boklm> that's it for me
18:49:48 <GeKo> oh, while we are at it: how do we handle the case where we have users with an alpha but we only update the stable version?
18:49:49 <MarkSmith> regarding generating incremental mar files, I am starting to think we might want to make that part of our Gitian-based build process (for reproducibility, etc.)  I am not sure....
18:50:13 <GeKo> what happens with the alpha users? do they get a hint that they need to switch to the stable version?
18:50:35 <GeKo> or are we from now on committed to always release new alpha versions, too?
18:51:45 <MarkSmith> I think we can advertise an update to the alpha channel that switches them to the release channel… but I am not 100% sure.  brade and I can test that....
18:51:52 <boklm> GeKo: when the alhpa version has been released a stable release, and there is not yet a new alpha ?
18:52:30 <MarkSmith> Of couse that would switch them away from alpha channel.
18:53:11 <boklm> MarkSmith: I am not sure either where is the best place to generate those incremental mar files
18:53:51 <GeKo> yes, but I wonder whether we want to commit to releasing an alpha always when a new ESR version is out
18:54:18 <GeKo> re incremental update: I think they should be in gitian for people to reproduce things
18:54:24 <mikeperry> we want incremental mars to be reproducible.. if we can do that outside gitian, that's OK, but I would be surprised if magic machine-specific metadata didn't get included
18:54:46 <GeKo> yes
18:56:20 <boklm> ok
18:57:20 <MarkSmith> boklm: Let us know if you want to work on incremental mar generation in gitian; if not, brade and I will tackle it (we were hoping to look at it later this week or next()
18:58:22 <boklm> MarkSmith: ok, I can let you tackle it
19:00:05 * MarkSmith can go next
19:00:22 <MarkSmith> Last week, Kathy Brade and I some time on bug triage and ESR31 work, including #13021.
19:00:39 <MarkSmith> We are in the process of creating a patch that will use the canvas prompt mechanism to also block access to canvas's isPointInPath() and isPointInStroke() APIs.
19:00:48 <MarkSmith> We also finished the work for #13047 (a big thanks to boklm for updating his tb-update-response code to accommodate the changes).
19:01:00 <MarkSmith> mikeperry: please review and merge the browser changes for #13047 (needed for 4.0a3)
19:01:12 <MarkSmith> Also, boklm has raised the issue of moving the https://github.com/boklm/tb-update-response/ code to its own repo at torproject.org.
19:01:34 <MarkSmith> Or we could consider simply adding it to builders/tor-browser-bundle.git (there are only a few files).
19:01:36 <GeKo> good idea
19:01:51 <MarkSmith> This week we will finish the work for #13021, do some ESR31-related code reviews, test the updater more in ESR31, and otherwise help with ESR31 in whatever way we can.
19:01:58 <MarkSmith> If we have time, we will work on generating incremental MAR files (for incremental updates) as part of the Gitian-based build process.
19:02:32 <MarkSmith> GeKo: good idea to move to torproject.org or good idea to fold into builders/tor-browser-bundle.git ?
19:02:41 <MarkSmith> Anyway, that's all for us.
19:03:04 <GeKo> I was responding to your first ieda but I am fine with the second one, too
19:03:24 * boklm is fine with both
19:04:24 <MarkSmith> I guess it is up to Mike then.
19:04:49 <MarkSmith> For the record, brade and I are fine with either approach (new repo or consolidate)
19:05:15 <mikeperry> keeping it in the main builders repo seems like the best plan I think
19:05:35 <mikeperry> especially if it might be the thing that generates incremental mars, or at least works with them
19:07:41 <boklm> ok
19:08:36 <MarkSmith> I think mikeperry or GeKo need to merge into builders/tor-browser-bundle.git (I am not sure who else has write access to that repo)
19:09:28 <boklm> ok, so I will make a branch that adds it in a directory in that repo
19:09:55 <GeKo> ping me and I'll look at it and merge it
19:10:20 <boklm> ok
19:13:43 <mikeperry> ok, do we have anything from support or anything else?
19:14:02 <armadev> mikeperry: i'm going to put out a new tor stable and rc today. fyi
19:14:22 <kernelcorn> sweet
19:14:27 * arthuredelstein can go
19:14:31 <mikeperry> ah, so 2.5.x will now be "rc" status?
19:14:38 <armadev> it already is. but yes.
19:14:54 <mikeperry> great. so we will just use that when we switch to FF31. that solves problems
19:15:00 <armadev> yep
19:15:25 <arthuredelstein> Last week I wrote patches for #13019, #13023, and #13198. I'm currently working on #11955, which I'll continue this week. Also I plan to do the rebase/squashing of tbb/esr31 as mentioned above.
19:15:56 <arthuredelstein> that's all for me
19:16:18 <mikeperry> ok, I will ask Camillo about pinning in person tomorrow
19:16:37 <arthuredelstein> great
19:18:54 <mikeperry> ok, so the chemspill target release date is Wednesday for Mozilla
19:19:15 <mikeperry> but they are doing FF31 first. it's not clear if they will have FF24 ready on wednesday too
19:19:47 <mikeperry> but I will merge all of our patches (basically the stuff in the changelog + #12998) so all we have to do is rebase
19:20:45 <mikeperry> and then we'll have to produce builds for 3.6.6 and 4.0a3
19:22:12 <mikeperry> oh crap
19:23:03 <mikeperry> MarkSmith: #13049 will cause us to break the updater if we bump the Firefox version to 24.8.1, right?
19:24:20 <mikeperry> I wonder if we should have our Firefox lie about its version, and use the old langpacks...
19:24:35 <MarkSmith> Actually, I think anything 24.* is OK.
19:24:57 <MarkSmith> It is only a problem if someone has an addon that is not compatible with whatever we upgrade to.
19:25:18 <armadev> s under control.
19:25:26 <MarkSmith> So the language pack addons are marked as compatible with 24.* which causes problems with 31.x (because of #13049)
19:25:28 <MarkSmith> I think ;)
19:25:31 <armadev> (ignore me, carry on)
19:26:00 <mikeperry> I think the langpacks advertise a specific FF version. I remember we had issues with this previously when we didn't strip the "esrpre" version suffix off the firefox version
19:26:39 <MarkSmith> Well, we should check.  I thought I had checked and saw "maxVersion: 24.*"
19:26:45 <MarkSmith> But I may be remembering wrong.
19:27:32 <MarkSmith> Do we replace the version within the langpacks during our build process?
19:27:35 <MarkSmith> Or something?
19:27:47 <GeKo> no
19:28:43 <mikeperry> <em:minVersion>24.8.0</em:minVersion>
19:28:43 <mikeperry> <em:maxVersion>24.*</em:maxVersion>
19:29:03 <mikeperry> for the 24.8.0 langpacks
19:29:23 <mikeperry> so we think it should still work for 24.8.1 then
19:29:38 <MarkSmith> OK, then I think the buggly code in 4.0a2 will be skipped because 24.8.1 is compatible.
19:29:41 <MarkSmith> Right.
19:29:48 <MarkSmith> buggy too
19:30:44 <MarkSmith> We should test a 4.0a2 -> 4.0a3 update once we have candidate builds.
19:31:01 <GeKo> yes
19:31:01 <mikeperry> ok.
19:31:05 <MarkSmith> Or sooner if we have close-to-complete code I guess.
19:32:20 <mikeperry> I guess we will just put the 4.0a3 candidate mars in the official updater location early and test the update asap?
19:33:24 <MarkSmith> We can also test by setting app.update.url.override to point to a test location.
19:33:52 <mikeperry> ah, ok. that's a better plan
19:33:52 <GeKo> yes and disable the cert pinning (if no tpo location is used)
19:34:24 <MarkSmith> if you use app.update.url.override cert pinning prefs are ignored (so don't deply that way)
19:34:36 <MarkSmith> ummm,
19:34:52 <MarkSmith> don't deploy that way (app.update.url.override is only for testing)
19:35:18 <GeKo> I see.
19:35:50 <GeKo> cool, that's even easier then
19:38:47 <hellais> mikeperry: was there a time when PT addresses were not in this file: https://gitweb.torproject.org/builders/tor-browser-bundle.git/history/HEAD:/Bundle-Data/PTConfigs/bridge_prefs.js?
19:39:00 <mikeperry> ok, so we have a plan. sounds good. I guess everybody be ready for building+testing on Wednesday/Thursday. I will keep an eye out for any earlier tagging by mozilla
19:39:35 <mikeperry> hellais: back when the PT bundles were separate things
19:40:21 <mikeperry> ie before 3.6-beta
19:40:28 <hellais> mikeperry: where should I be looking? I want to get all of the PT addresses that have ever been included inside of a TBB.
19:40:42 <mikeperry> not sure. dcf and asn were handling those old bundles
19:40:47 <mikeperry> I have no idea how they built them
19:41:00 <mikeperry> for a long while, they were using the old TBB 2.x build system  some mods
19:41:05 <mikeperry> err + some mods
19:41:30 <hellais> ah I see
19:42:02 <hellais> thanks
19:44:00 <mikeperry> ok, tags may appear for 24.8.1 tomorrow. I will do my best to rebase ASAP, but I will be at a meeting at Mozilla+EFF
19:44:24 <mikeperry> I think that's it for the meeting then?
19:46:05 <mikeperry> alrighty
19:46:08 <mikeperry> #endmeeting