18:01:57 #startmeeting tbb-dev 18:01:57 Meeting started Mon Apr 13 18:01:57 2015 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:57 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:48 hello everyone. let's get started 18:03:01 hi 18:03:40 Last week, other than helping Georg with 4.0.7 and 4.0.8, I mostly ended up doing non-TBB work (Android and Tor org stuff). I also wrote a patch for start-tor-browser to add --register-app and --unregister-app command args, which still needs a ticket. 18:04:07 This week, I plan to review patches, think a little bit more about #15482 and #15514, and help with #4100. 18:05:29 I think we should aim for having everything mergeworthy in 4.5-stable by the end of the week 18:05:57 which means trimming down https://trac.torproject.org/projects/tor/query?keywords=~tbb-4.5-alpha&status=!closed and/or making sure everything is claimed 18:06:54 that's it for me for now 18:07:37 uh mine is short 18:08:03 go ahead 18:08:15 I wrote the rage hack for obfs4proxy to have a internal socsk5 server and will likely merge/tag obfs4proxy 0.0.5 with it this week 18:08:44 I know it's not prefered, but, neither is my branch sitting in limbo, and this fixes it for everyone who uses obfs4proxy which also includes debian and tails now 18:08:49 heh, ok. was this because of the debian deadline? when is that? 18:09:10 no, it's because the stupid branch has sat in limbo for months 18:09:11 >.> 18:09:54 and just giving you guys an overlay patch or a different branch 18:10:03 doesn't solve the problem for orbot/tails/debian/arch/etc 18:10:06 has dcf been busy elsewhere lately? that doesn't seem typical for him 18:10:13 dunno 18:10:36 anyway, my branch is a cleaned up/improved version of the goptlib code so 18:10:44 it works, it has tests 18:11:10 since my obfs4 bridge has ipv6 connectivity, I even made sure that works 18:11:18 (works great) 18:11:48 that's it for me unless y'all have other things that are on fire that needs my attention 18:13:44 ok. so if this is instead of #12535 for 4.5-stable, is there a ticket for it?or should we make one just to use the 0.0.5 tag? 18:15:11 I'll make a ticket when I tag it 18:15:27 ok cool. please add keyword tbb-4.5-alpha 18:15:31 was gonna give y'all and the pt meeting people a chance to change my mind about doing this 18:15:58 ok. I am indifferent. I understand the need to make sure it gets in debian+tails 18:16:09 but I think my rationale for merging my rage branch is solid enough 18:16:16 so I won't object. I just find it weird for dcf to be unresponsive 18:16:48 he is normally very attentive to stuff and helpful. 18:17:19 +3/away 18:17:21 yeah I'll bug him about it 18:19:51 err, +1 on SOCKS5 instead of SOCKS4a, also i am not away anymore 18:21:12 ok, who's next? 18:21:25 here is what I did: 18:22:02 I was actually afk most of the week due to non-Tor things this week but I am back to a normal schedule 18:22:16 at least I managed to help with our releases 18:22:36 today I spent time on #4100 and #15599 18:22:51 and gave the tor browser user manual a closer read 18:23:27 tomorrow I plan to update #4100 with my findings and attach a patch for review 18:23:44 then reviewing other stuff is on my plate 18:24:15 and I think I try to get #15599 fixed as it worries me even if it is not as bad as I first thought 18:24:34 I think I can start looking at #15598 as well 18:24:43 that's it so far 18:25:21 #4100 needs a patch? interesting 18:25:49 well, just resetting our reduced keep-alive and a better comment explaining things 18:26:06 ah, ok great 18:26:09 I think everything is fine at least wrt to no spdy things 18:26:45 not sure about the latter yet but as we have spdy disabled anyway this is not urgent 18:26:56 and better handled with our HTTP/2 audit IMO 18:28:34 I agree wrt HTTP/2 over spdy.. 18:28:53 I wonder if Google will switch to HTTP/2 instead of spdy.. 18:29:17 (QUIC lol) 18:30:17 I think so but even if we decide to enable spdy additionally I think auditing both wrt to keep-alive issues makes sense as they are quite similar (at least in this regard) 18:30:55 s/auditing both/auditing both together/ 18:31:25 http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html ("We plan to remove support for SPDY in early 2016…") 18:31:25 ok 18:32:48 * mcs can go next 18:33:33 During the past two weeks, Kathy and I reviewed patches and did some bug triage. 18:33:40 We looked at #15532 but decided to defer it for now. 18:33:47 We investigated #15491 and closed it (no changes needed). 18:34:05 We put a couple of Tor Launcher patches out for review: #13576 and #15657. 18:34:13 Assuming that those patches pass review, we will need to decide if they should be included in TB 4.5. 18:34:20 We also did some miscellaneous updater testing for TB 4.0.8 and 4.5a5. 18:34:25 Finally, we discussed #15637 and thought about how we can make update testing part of the QA process. 18:34:35 Is that worth pursuing? I am not sure who should own the testing task, but when a build is announced on tor-qa we would need to have signed MAR files ready, 18:34:40 we would need a test https server to host the files (we could probably just use people.TPO), 18:34:45 and we would need to have a way to create tweaked .htaccess and update.xml files (suitable for use on the test https server). 18:34:51 This week we will help with other remaining 4.5 issues and also look at #14716 and #14387. 18:34:56 That's all for now. 18:36:39 mcs: I can look at the update testing part 18:37:42 I am a bit reluctant here as I definitely don't want to reduce the time between tor-qa post and release 18:37:54 boklm: Thanks. One issue is that I am not sure when mikeperry and GeKo actually sign the MAR files. 18:38:44 yeah, signing is the bottleneck here, since it must be done offline and requires a lot of copying+uploading of many MAR files 18:38:53 yup 18:39:11 So maybe it is enough to have the new text boklm added and for us just to be careful ;) 18:39:24 that's what I currently think 18:39:35 especially as the updater was working as expected 18:39:54 OK. I just wanted to ask here. 18:40:39 GeKo: speaking of signing, do you know what this "AppLocker" publisher rule thing is from #3861? 18:41:05 good question I almost forgot about it. 18:41:37 I think they are asking for each embedded exe and dll to be signed, not just our installer? 18:41:39 no, but I should look for some information about it 18:42:28 seems so, but afaict Mozilla is not doing that, so I was wondering why that is no broader issue 18:42:31 (but I don't know anything about AppLocker) 18:42:53 I'll investigate a bit I think 18:42:54 it is perhaps an option or additional AV product or something? 18:43:05 probably 18:43:12 GeKo: Good question. For some reason, I thought Mozilla was doing that (or used to?) But I may be wrong. 18:43:36 https://technet.microsoft.com/en-us/library/dd759117.aspx 18:44:37 wonder which versions of win8 support it 18:44:52 everything, or just the "I paid too much for this Edition" 18:46:35 And it does look like firefox.exe is signed by Mozilla (I just checked 37.0.1 on Win7) 18:47:20 interesting 18:47:21 ugh, that's a lot of signing :/ 18:47:30 ugh indeed. 18:47:45 and it might be orthogonal given https://bugzilla.mozilla.org/show_bug.cgi?id=902771 18:48:02 we'll see 18:49:19 (so wait, pt executable sna dstuff will also need signatures right? :/) 18:49:51 it does sound like it's mostly enterprise/"I paid too much for this Edition" editions https://technet.microsoft.com/en-us/library/dd759131.aspx 18:52:39 * arthuredelstein can report next 18:53:02 Over the last week I wrote patches for #13875, #15651, #14429, and #15502 and https://bugzilla.mozilla.org/show_bug.cgi?id=418986. My patch in #14429 looks like it still has problems dealing with the window size after "New Identity", so I'll work on that this week. I thought perhaps I can also start looking at #15579 and #15196. 18:53:44 That's it. 18:54:56 (#15672 is my desktop app registration ticket, btw) 18:56:04 * boklm can report next 18:56:28 I posted a patch in #15670, and fixed #15643 18:56:35 I extended the tbb-qa.yml file format to allow selecting a tor-browser commit to build and run mozilla unit tests, using something like this: http://people.torproject.org/~boklm/builds/tbb-qa.yml 18:56:40 this week I'm planning to: 18:56:45 - add documentation about this on the wiki 18:56:51 - add an option to select a git repository (to test a commit in a personnal repo) 18:57:02 - add an option to test all commits in a branch and show differences 18:57:14 that's it 18:58:08 that sounds great boklm. should help us a lot with 38 rebase work. send a mail out to tbb-dev when you've got the wiki updated and everything is ready? 18:58:25 mikeperry: yes 18:58:34 sounds very useful 19:00:00 For the 38 rebase, how do we plan to divide up the work? 19:00:02 arthuredelstein: I still have a soft spot for #14429, so even if it ends up preffed off, you can still try to polish it for 4.5-stable this week if you like. 19:00:26 I am also fine with it adjusting in 100x100 multiples, so long as the initial window size remains 200x100 19:00:43 mikeperry: OK, I'll try. I always get surprised by new weird bugs. :( 19:02:13 mcs: so I plan to review all of the "Firefox for developers" APIs and undocumented bugs for each Firefox release, as well as do the networking review/grep. I could use a second set of eyes on the Firefox docs+bugs (maybe GeKo's?) 19:02:32 I am not sure about switching to 100x100. What is the rationale for that? 19:02:51 I was also planning on trying to squash down our patches a bit 19:02:52 yeah, I can have a look at the ff docs and bugs as well 19:04:25 GeKo: In the new version of #14429, I don't shrink the window when it is maximized. Instead I zoom the contents to fill the height. So we're left with margins at left and right. I think users will be much less bothered by 100px of wasted space than 200px. But it's true that 200px is not terrible, at least for reasonable screen sizes. 19:05:00 my thinking was that resizers will likely be noticable as such, because they will likely have very large window sizes, so making the resize jumping smaller seems OK to me 19:07:09 I see. Seems fine to me then. 19:07:28 mikeperry: Sorry, I'm not sure I quite follow 19:07:34 wrt rebasing individual patches and fixing the tests, I am not sure how to divide that up.. 19:08:58 mikeperry: OK. It sounds like dividing up should wait until after patches are squashed in any case. 19:09:11 arthuredelstein: I have not yet tested the zooming version of #14429 actually. my comments might not be valid wrt the window resolution of the new version... but my thinking was the 1 bit extra entropy for 100x100 instead of 200x100 might not even be 1 bit 19:09:30 mikeperry: Aha, I see. 19:09:40 yes 19:11:07 I had thought about introducing a set of allowed sizes that gradually increase in interval, like 100, 150, 200, 300, 400, 500, 600, 800, 1000. 19:11:27 But I fear that will be more confusing to users. 19:14:44 yeah, I suspect so. there seem to be enough issues with just a simple algorithm also.. I could see weird things happening at one of the resolutions but not others, due to some toolbar+rounding interaction, etc 19:15:55 True. I'll leave it at 100x100 for now. 19:19:41 ok. I think that wraps it up? I think we seem to be in good shape for 4.5. Target merge date Thurs/Friday, and I will kick off a test build then, perhaps? 19:20:18 sounds good to me 19:21:43 ok. thanks everyone. Hopefully by this time next week we'll have some candidate builds for the best TBB ever ;) 19:21:53 #endmeeting *baf*