18:01:20 #startmeeting tbb 18:01:20 Meeting started Mon Oct 6 18:01:20 2014 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:20 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:42 so last week, I merged everything pending for ff31, and we began producing nightlies. I also wrote the status report, and reorganized+retagged all of our tickets for October 18:02:56 the remaining Firefox31-specific tickets are https://trac.torproject.org/projects/tor/query?keywords=~ff31-esr&status=!closed 18:03:48 we need to decide if we want to do a 4.0a4 release to test the updater transitioning to 31esr, or if it will be too distracting and we should just test that with the nightlies 18:04:16 we have 8 days until we need to switch all the 3.6 users to 4.0 w/ ff31 18:04:34 then lets not release aother alpha before 18:04:42 *let's even 18:04:50 and another, too 18:04:54 We should be able to test with nightlies and with candidate builds. 18:05:39 (Kathy and I are going to test with current nightlies today) 18:05:58 Obviously, we might miss some scenario that users will encounter.... 18:06:45 oh, I also did some more network cost and scalability-related analysis last week, and probably a few other bureaucratic things not worth mentioning 18:07:01 * isis attends the meeting 18:07:59 shall we upgrade all of the alpha users to the stable channel? or make a new channel? 18:08:36 what do you mean with "new channel"? 18:09:34 the updater has a notion of channels, and will keep you on the one you started with.. ie stable or alpha 18:10:05 there was an issue in the alphas where they got angry because it seemed they couldn't find an updater manifest, did that get reported/fixed? 18:10:09 yes, maybe I should have asked 'what do you mean with "new"' then 18:10:31 well I believe right now we only have an alpha channel 18:11:20 isis: yes, this issue is fixed 18:11:21 I think keeping an alpha channel and a stable one if we can afford is is fine 18:11:29 isis: I think that was fixed. somehow the .htaccess file wasn't synced when I first put it up 18:11:50 or maybe a beta and stable channel but not more than two 18:12:23 would it be crazy if we released a esr31 alpha with obfs4 next week? 18:12:29 *an 18:12:38 just to keep the alpha users on the channel 18:12:45 + some noew alpha thingy 18:12:48 *new 18:12:55 I am looking at this ticket list and I think we want to have things like #11955 go out in an alpha or two first 18:13:06 because that one in particular can break a lot of things 18:13:13 good idea 18:13:18 I agree 18:14:48 there's a few other things on this list that don't strictly need to be in 4.0-stable 18:15:16 Take them off the list now (reduce priority)? 18:16:55 ok, I am doing that now 18:17:28 who wants to give their update while I do that? 18:18:04 On the update channel issue, if we are going to maintain an alpha channel by doing releases on a regular basis, we should not upgrade the alpha users to stable. 18:18:24 But historically, it seems like TBB alpha users have switched to stable once it comes out. 18:18:33 And then some time later we do another alpha release. 18:18:45 (different model than Mozilla but we have a much smaller team 18:18:48 ) 18:19:08 We need to at least get everyone to ESR31 ASAP 18:19:32 okay, here is my update: 18:19:49 MarkSmith: is there some settings that users can easily change if they want to switch back to alpha channel after being updated to stable ? 18:20:36 I wrote some test for the resource timing API, I fixed two regressions wrt the hardening wrapper in the ESR 31 related gitian descriptor 18:20:41 *tests 18:20:58 and I backported and tested the patch for #13027 18:21:16 I am currently writing a test for it taking nested workers into account as well 18:21:34 I hope I can finish that tomorrow 18:22:01 boklm: maybe they can just set the pref app.update.channel = alpha but I have not tested it. 18:22:18 this week I'll look at bolkm's incremental updates patch and help fixing the last urgent issues before releasing the ESR 31 based Tor Browser 18:22:30 that's it so far. 18:24:39 ok. who's next? 18:25:18 * arthuredelstein can go next 18:26:15 Last week I worked on certificate pinning, #11955. 18:26:52 Also I updated my patch for #5926 18:27:35 and also for #13198 18:27:49 This week my plan is to try to finish up the certificate pinning backport 18:28:04 that's it for me 18:28:29 * MarkSmith can go next 18:28:47 Last week, Kathy Brade and I spent some time trying to build 4.0-nightly (ESR31) so that we could test some 4.0-alpha-3 to 4.0-based-on-ESR31 update scenarios. 18:28:59 Unfortunately, we ran into Yet Another Strange Build Failure (when building binutils). 18:29:04 Today we got past that failure by deleting the target-* VM images and restarting the build. 18:29:17 We already have Linux builds and I am hopeful that Windows and Mac will succeed as well. 18:29:26 good to hear :) 18:29:27 We also reviewed boklm's changes for #13324 and we spent a lot of time on non-Tor stuff. 18:29:40 This week we plan to do the updater testing I already mentioned and help with any urgent ESR31 issues. 18:29:48 We also plan to review deliverables from our current contract and get feedback from Mike on priorities. 18:29:53 That's all for us. 18:31:19 * boklm can go next 18:31:53 last week I made the update_responses script generate incremental MAR files and opened ticket #13324 18:32:23 I looked at the tor_fte_httpproxy failures we had on 3.6.6, but could not reproduce them now. So it looks like it was a temporary failure. 18:32:56 I also fixed and improved uploads to virustotal (#11263). They are now on this page: http://93.95.228.164/reports/index-browserbundle_virustotal.html 18:33:44 This week I plan to fix the testsuite on 4.0 releases (GeKo mentioned a change in LD_LIBRARY_PATH which is likely the reason it doesn't work) 18:33:54 I also plan to spend some time looking at Tor Messenger build process 18:34:07 that's it for me 18:35:41 boklm: for your incremental MAR files update, perhaps you want to check if you have the mar-tools input zip, and the previous TBB version directory, and then extract the mar-tools zip into a directory that you can temporarily put in the path? 18:36:20 mikeperry: ah yes, I can do that 18:36:50 I am also wondering how we want to handle these.. I think they should probably also get their own separate sha256sums.txt file 18:38:13 how do we plan to deploy that? like mozilla serving both: incremental if updating, say, from the last version and otherwise full update? 18:38:17 oh, and were you able to get an mbox test working for #13020? 18:38:28 Is that a separate sha256sums.txt file for incremental mars or all mars? 18:38:34 GeKo: yes 18:38:40 good 18:38:42 MarkSmith: I think just the incremental mars 18:38:51 mikeperry: OK 18:38:56 since they need extra magic and a previous release to build 18:38:58 mikeperry: yes, I have an mbox test, I need to run it on 4.0 nightly 18:41:21 maybe we should include the word 'incremental' in the incremental mars filenames, so they are easier to exclude when generating the sha256sums.txt ? 18:41:41 ah, yes, probably 18:42:13 So who owns the task of modifying tor-browser-bundle/gitian/Makefile to add new targets related to boklm's script (including generation of incremental mar files)? 18:42:53 [distraction; don't pay attention to this now] djb has a new curve, curve41417, which does ECDH in constant time with k≥2⁸⁰ http://cr.yp.to/ecdh/curve41417-20140706.pdf 18:43:45 s/80/200/ even 18:43:47 MarkSmith: probably should be part of boklm's branch, too I think 18:43:58 MarkSmith: I can do that 18:44:07 boklm: thanks! 18:45:07 I am not sure if we'll have incrementals for 4.0-stable. it will be a close call. I will put the tag on it but leave it at 'normal' priority 18:45:47 ok 18:46:47 actually, it won't make sense to have them for 4.0-stable, if we keep the channes separate.. they would be for like 5.0-alpha-1 anyway 18:47:02 yes 18:47:18 but we can use it for 4.0.1 perhaps, if it seems to work out ok 18:47:24 sounds like a good idea to test them there to, first 18:47:25 yes 18:47:43 *too 18:48:12 The good news is that if applying the incremental mar fails, the complete mar should be used as a fallback. 18:48:41 yeah, "should" ;) 18:49:01 (We have seen that work with Tor Browser in the "lab") 18:49:10 Finger crossed.... 18:49:14 Fingers too 18:50:13 ok, I think I have updated the ff31-esr tickets and prioritized them. https://trac.torproject.org/projects/tor/query?keywords=~ff31-esr&status=!closed 18:50:38 stuff with priority major we really want to try to get done in some form. stuff in normal probably can wait 18:52:34 #13016 and #13025 need owners. I think #13346 is just a pref change 18:53:51 brade and I can take #13016 18:54:05 (assuming our updater tests go OK, we should have tme) 18:54:08 time 18:55:31 I think I can work on #13025 if nobody else is stepping up. 18:56:01 and, yes, #13346 should only be a pref change 18:56:17 I am not convinced about that "saves to disk part" yet 18:56:29 s/about/of/ 18:56:30 ok, I was just about to offer to take it, but I think between #13020 and the release management stuff, and some other background noise I might not get to it 18:57:01 What is our deadline/goal for getting all code changes in? 18:57:40 Thursday, I guess? 18:58:04 then we could have one nightly, or so, while rebasing 18:58:15 mozilla's tags will probably appear tomorrow or wednesday. we should be tagging ourselves and building by thursday/friday, so I can get a build up before the weekend to tor-qa 19:01:44 ok 19:01:55 anything else? 19:04:18 ok, I think we are good then. let's hope all goes smoothly between now and next monday :) 19:04:49 #endmeeting