18:01:36 #startmeeting tbb-dev 18:01:36 Meeting started Tue May 26 18:01:36 2015 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:36 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:15 * tjr is here 18:02:17 alright, let's get started with our observed tbb-meeting (due to the US holiday) 18:02:41 I'll give my update first 18:02:54 Last week, I updated https://trac.torproject.org/projects/tor/wiki/org/roadmaps/TorBrowser a bit, reviewed the Firefox developer docs since FF31 (#16090), worked on a funding proposal, and did some emergency non-TBB work (fixing bandwidth authorities). 18:03:07 This week, I plan to finish up the funding proposal work, file some additional tickets for #16090, and start either the networking code review, or deeper new feature review. 18:03:52 we were also accepted to the HTTP/3 workshop in late July in Germany. they want us to decide who we're sending by June 1st, I think 18:04:33 most likely GeKo or I will end up doing that. I think they only want 1 rep per org 18:05:03 that's it for me for now. I'm sure we'll have more esr38 stuff to talk about as the meeting progresses 18:06:16 my update: having Mike P. not object in principle to device driven Tor Browser bridge configuration i am still working on a JSON based syntax for Tor Launcer to get bridge and PT configuration (not nothing else?) from a device for use in a local network. The end. 18:08:27 * mcs can go next 18:08:32 coderman_: cool. happy to look at a protocol design sketch to comment 18:09:08 What sort of device would that be? 18:09:22 coderman_: it might also be nice if TBB could detect that the network supports this protocol somehoiw, so we can only give te user the option if it is indeed possible.. so happy to hear thoughts on that, too 18:10:29 arthuredelstein: a Tor Router/Tor firewall. like https://github.com/radicallyopensecurity/netaidkit. coderman mentioned it on tor-dev or tor-talk some months back... 18:10:57 thanks, makes sense 18:11:04 a device that might exist, but in theory, this would be useful for any users in a similar situation (e.g. generic - not specific to device, even if only one device uses it.) arthuredelstein: serqet345qt265xp.onion 18:11:05 we should resume the meeting for now, though. go ahead mcs 18:11:11 Last week, we tested our patch for #16014. 18:11:17 And we finished rebasing the updater patches onto ESR 38. 18:11:22 We finished the changes for #15145. 18:11:30 We did not push that fix to the main Tor Launcher repo. yet because we added a couple of new strings (extra localization work is presumably OK for 5.0 but not desired for TB 4.5.x). 18:11:37 We also did some miscellaneous bug triage. 18:11:42 This week, we plan to spend some time reviewing the Firefox developer docs for the releases since Firefox 31 (#16090). 18:11:51 arthuredelstein and GeKo: Please let us know if there are any patches you want us to help rebase onto ESR 38 or if there is anything else we can do to help with the ESR 38 efforts. 18:11:58 netaidkit is a better first use 18:11:58 That's all for now. 18:12:30 sorry mcs, et all. end of my interrupts 18:13:39 here is what I did: 18:14:24 I spent most of the time to get ESr 38 working with gitian and it looks good. barring some unforseen issues while testing the bundles I got everything working on all three platforms 18:15:16 * GeKo ugh my english 18:15:39 I spent some time reviewing proposal related things 18:15:54 I looked into fixinf #16026 18:16:11 and reviewed #15984 18:16:48 this week I'll open some more tickets for the Gitian related ESR 38 transition and attach all the patches I have 18:17:19 then I'll start looking at fixing and investigating ESR 38 features 18:17:29 that's all for now 18:18:24 * arthuredelstein can go 18:18:48 Last week I finished rebasing the patches in tor-browser.git for ESR 38. 18:19:01 And I added all patches from mcs and brade. 18:19:20 Here's the branch: https://github.com/arthuredelstein/tor-browser/commits/tb_GECKO380esr_2015050513_RELBRANCH 18:19:27 oh, great! 18:19:35 This week I'm going to re-order those patches a little, and look through them again carefully 18:20:13 It would be good if anyone has time to look over the patches as well to see if there are any obvious mistakes. 18:20:27 ok, after that pass is complete, everyone should also review the patches with their name on them, to check for any odd issues, merge damage, or new things we need to do for FF38esr 18:21:04 Also this week I'll try running it with Tor Launcher and Tor Button to see if we need to make any fixes. 18:21:25 That's it for me. 18:22:04 We may have a Torbutton fix (we will check) 18:22:12 we need to make fixes :) 18:22:45 I can't run the bundles currently due to some Torbutton breakage I need to track down (tomorrow) 18:23:22 GeKo: did we have to update any compilers for FF38esr? 18:24:45 yes, for windows we need a fairly recent mingw-w64 18:25:04 are we still able to use Ray's compiler with the newer SDK? 18:25:12 it seems so, yes 18:26:10 cool 18:26:25 oh, what news on the WeekDH front? did patches appear for esr31 yet? 18:26:38 no :( 18:27:01 we could disable the DHE ciphers in tor browser which works fine for me 18:27:15 but who knows what this breaks 18:28:19 hrmm.. I think we should do that if they're not going ot backport to esr31 18:28:28 but probably shouldn't rush that 18:28:55 "I'm treating the 31 changes with less urgency, since I'm told that we won't need that for a few more weeks. I need to consult with :kaie about what is needed." 18:29:16 that's the state of this topic as far as I know 18:29:31 mcs: I agree wrt holding on merging #15145 for a bit, to avoid messing with translations. we're still getting new string translations for 4.5. updating the ticket with the branch and a note about not merging it yet seems like a good plan for now 18:29:34 FWIW, Mozilla published an extention to do just that: https://addons.mozilla.org/en-US/firefox/addon/disable-dhe/ 18:29:42 "Firefox 39 will include changes that will increase the minimum strength of keys to 1024 bits." 18:29:53 yes 18:29:56 mikeperry: will do 18:30:08 but I think before shipping that extension we'll flip the prefs 18:30:40 GeKo: agreed 18:32:01 do we have a boklm? I think I like the feature branch idea he wrote to tbb-dev. it's perhaps worth trying for esr38? 18:32:06 * boklm can go next 18:32:19 Last week I've met intrigeri, and we started integrating the tbb testsuite into their Tails testsuite 18:32:27 I have been thinking about a different way to organize tor-browser patches in git to make them easier to test, and sent a proposal about this on tbb-dev: https://lists.torproject.org/pipermail/tbb-dev/2015-May/000275.html 18:32:28 yay 18:32:35 And I started pushing some of the patches individually to Mozilla Try to see which ones make some tests fail 18:33:47 This week I will try to finish adding a test for #15138, and work on the feature branch idea for esr38 if people think it's a good idea 18:34:13 that's all for me 18:34:35 I like the idea, the only concern I would have is that it could be a little complicated to keep multiple branches correctly in sync. 18:34:56 hrm... what about issues only visible if a lot of patches interact? 18:35:02 which are on different brances 18:35:48 One possible alternative might be to have a test script that cherry-picks each individual branch to a bare ESR38 branch and then submits to try. 18:36:23 arthuredelstein: keeping which branches correctly in sync ? 18:36:42 yeah, some of our patches will depend on the prefs being updated for them.. and doing that in each topic branch will make merging them painful without some additional effort/glue 18:36:56 boklm: the topic branches 18:38:07 to prevent fingerprinting: any change users will be steered away from setting do no track in the near future? (like they are steered away from changing the size of the browser window) - the wording in the current TB is might suggest to some that enabling dnt is beneficial #7921 18:38:36 arthuredelstein: we can have a script to check if all the topic branches are merged into the main branch 18:39:12 boklm: I think GeKo and mikeperry expressed my concern better than I did. 18:40:38 arthuredelstein: for the cherry-pick of individual commits to a bare ESR38 branch, it does not work for all patches, because some of them depend on a previous patch 18:40:55 one benefit from topic branches is that we might be able to get away with not rebasing them constantly for each point release, and still keep track of everything cleanly 18:41:17 boklm: So maybe in the cherry-picking script, you could include those special cases by cherry-picking dependencies as well. 18:42:15 yes, but what if we get to know about dependencies only due to failing tests? 18:42:15 arthuredelstein: for instance a patch adding a test to tbb-tests/mochitest.ini depends on the previous patches creating/modifying this file 18:42:51 there might be some weird interaction that is hard to see 18:43:11 (which is why there are tests in the first place :) ) 18:44:08 boklm: Right, so for that patch the script would need to cherry-pick the previous patches as well, and submit the resulting branch to try. 18:45:56 I think it's worth experimenting with 18:45:57 arthuredelstein: in some cases, it's not possible to find the dependency automatically, for instance a patch adding a test for a feature added by an other patch 18:46:21 mikeperry: yes, I agree 18:47:17 I also agree it's worth experimenting. 18:47:48 * tjr can go next... 18:49:39 Mostly I worked on the bandwidth authority stuff for the past week. But I did look at more heap partitioning in jemalloc 3. 18:49:44 (email here: https://lists.torproject.org/pipermail/tbb-dev/2015-May/000272.html ) 18:49:51 I have jemalloc3 compiling in esr38, and accessible in a replace library. 18:50:18 the library successfully randomizes an arena choice based on an uninitialized variable :) 18:50:26 nice 18:50:59 I tried looking at using the backtrace call available in execinfo.h as a basis of walking the stack to randomize more deterministically (heh) 18:51:04 but that was impossible slow 18:51:25 So I'm going to look at walking the stack manually using ASM. =P 18:51:29 memory tags do not seems to be a fruitful area of exploration, unless I'm grossly misunderstanding them. 18:52:13 And the other area I need to look at is trying to figure out where we would want to do the segmentation ourselves in the JS engine to (e.g.) move arrays and strings somewhere else 18:54:11 I'm probably not going to be able to work on this for a few weeks due to travel and other commitments, and the bwauth stuff taking priority 18:54:20 that's all I have 18:55:20 hrmm.. that sounds promising 18:56:01 it seems like something we should shoot for having in TBB5.0 in August 18:56:31 mikeperry: Can we (SysAdmin Team) do anything to help you on #15706? From reading the history I have the impression it can be closed. What's your opinion here? 18:57:14 tjr: chrome only segments ArrayBuffers and strings, right? Or do they do more now? 18:57:38 I am unsure. Back when I did the report, that was it 18:58:05 I confess I still don't entirely understand the versinioning system. 5.0 is still ESR31, right? 18:58:14 :) 18:58:22 it'll be ESR 38 based 18:58:32 I'll have to look and see if jemalloc3 has changes between 31 and 38 we would need to backport. (probably) In addition to one or two other patches on top. 18:58:43 qbi: I have some munin scripts I started working on sitting in my homedir in aroides. they are not finished yet. I have some questions about munin (how often it runs, if I can config that, where the graphs go, and what is the bare minimum config options I need to provide) 18:59:37 Okay, 38-based. If there's a working 38 branch in someone's repo they'd recommend, I can start putting code off of that branch, so you can actually view the patches and things I've written 19:00:10 tjr: see #15196 comment 7 19:00:12 tjr: https://github.com/arthuredelstein/tor-browser/commits/tb_GECKO380esr_2015050513_RELBRANCH is the current working branch 19:01:01 okay, I will work on that and push my changes up to github sometime soonish 19:04:22 qbi: how often does munin run? do you like writing munin plugins? 19:06:32 any other tbb meeting topics/questions/updates? 19:07:11 arthuredelstein: can you send out a mail to tbbb-dev when you believe the patches have solidified enough for people to look over their own patches for any potential issues or merge rot? 19:07:34 Sure, will do 19:09:26 Related to the Torbutton fixes I mentioned earlier, see #16200. 19:09:47 Nothing else from me for the meeting. 19:10:54 #16090 could use more eyes, and I need to do a network syscall review, but it sounds like we're otherwise in good shape for esr38! 19:12:25 if we have the time I think I'd like to have a closer look at HTTP/2 19:12:38 if not we can easily disable it 19:13:14 even though it is not optimal we might be able to tune our website traffic fingerprinting defense with it 19:13:31 sounds at least like a fun thing to look at :) 19:13:32 yeah, I think that can come after we get an alpha build out based on ff38 if need be, but I do want to do something aout it for 5.0 for sure 19:13:44 yes, agreed 19:15:27 ok, anything else? 19:15:42 (not for the meeting) 19:15:44 For the ESR38 branch, should I just use master of tor-browser-bundle and point versions.alpha to the branch? 19:16:17 uhm, that breaks currently 19:16:57 if have a bunch of patches that fix things which are not merged yet 19:17:30 okay; that's cool - is that branch in git? 19:17:46 I'll prepare one for you tomorrow and ping you when I am done 19:18:13 okay, sure - feel free to deprioritize it as much as you wish :) 19:19:07 ok, I think that wraps up the meeting then. thanks everyone! 19:19:13 #endmeeting *baf*