18:01:20 <mikeperry> #startmeeting tbb
18:01:20 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:02:42 <mikeperry> 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 <mikeperry> the remaining Firefox31-specific tickets are https://trac.torproject.org/projects/tor/query?keywords=~ff31-esr&status=!closed
18:03:48 <mikeperry> 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 <mikeperry> we have 8 days until we need to switch all the 3.6 users to 4.0 w/ ff31
18:04:34 <GeKo> then lets not release aother alpha before
18:04:42 <GeKo> *let's even
18:04:50 <GeKo> and another, too
18:04:54 <MarkSmith> We should be able to test with nightlies and with candidate builds.
18:05:39 <MarkSmith> (Kathy and I are going to test with current nightlies today)
18:05:58 <MarkSmith> Obviously, we might miss some scenario that users will encounter....
18:06:45 <mikeperry> 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 <mikeperry> shall we upgrade all of the alpha users to the stable channel? or make a new channel?
18:08:36 <GeKo> what do you mean with "new channel"?
18:09:34 <mikeperry> the updater has a notion of channels, and will keep you on the one you started with.. ie stable or alpha
18:10:05 <isis> 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 <GeKo> yes, maybe I should have asked 'what do you mean with "new"' then
18:10:31 <mikeperry> well I believe right now we only have an alpha channel
18:11:20 <boklm> isis: yes, this issue is fixed
18:11:21 <GeKo> I think keeping an alpha channel and a stable one if we can afford is is fine
18:11:29 <mikeperry> isis: I think that was fixed. somehow the .htaccess file wasn't synced when I first put it up
18:11:50 <GeKo> or maybe a beta and stable channel but not more than two
18:12:23 <GeKo> would it be crazy if we released a esr31 alpha with obfs4 next week?
18:12:29 <GeKo> *an
18:12:38 <GeKo> just to keep the alpha users on the channel
18:12:45 <GeKo> + some noew alpha thingy
18:12:48 <GeKo> *new
18:12:55 <mikeperry> 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 <mikeperry> because that one in particular can break a lot of things
18:13:13 <GeKo> good idea
18:13:18 <arthuredelstein> I agree
18:14:48 <mikeperry> there's a few other things on this list that don't strictly need to be in 4.0-stable
18:15:16 <MarkSmith> Take them off the list now (reduce priority)?
18:16:55 <mikeperry> ok, I am doing that now
18:17:28 <mikeperry> who wants to give their update while I do that?
18:18:04 <MarkSmith> 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 <MarkSmith> But historically, it seems like TBB alpha users have switched to stable once it comes out.
18:18:33 <MarkSmith> And then some time later we do another alpha release.
18:18:45 <MarkSmith> (different model than Mozilla but we have a much smaller team
18:18:48 <MarkSmith> )
18:19:08 <MarkSmith> We need to at least get everyone to ESR31 ASAP
18:19:32 <GeKo> okay, here is my update:
18:19:49 <boklm> 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 <GeKo> 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 <GeKo> *tests
18:20:58 <GeKo> and I backported and tested the patch for #13027
18:21:16 <GeKo> I am currently writing a test for it taking nested workers into account as well
18:21:34 <GeKo> I hope I can finish that tomorrow
18:22:01 <MarkSmith> boklm: maybe they can just set the pref app.update.channel = alpha but I have not tested it.
18:22:18 <GeKo> 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 <GeKo> that's it so far.
18:24:39 <mikeperry> ok. who's next?
18:25:18 * arthuredelstein can go next
18:26:15 <arthuredelstein> Last week I worked on certificate pinning, #11955.
18:26:52 <arthuredelstein> Also I updated my patch for #5926
18:27:35 <arthuredelstein> and also for #13198
18:27:49 <arthuredelstein> This week my plan is to try to finish up the certificate pinning backport
18:28:04 <arthuredelstein> that's it for me
18:28:29 * MarkSmith can go next
18:28:47 <MarkSmith> 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 <MarkSmith> Unfortunately, we ran into Yet Another Strange Build Failure (when building binutils).
18:29:04 <MarkSmith> Today we got past that failure by deleting the target-* VM images and restarting the build.
18:29:17 <MarkSmith> We already have Linux builds and I am hopeful that Windows and Mac will succeed as well.
18:29:26 <GeKo> good to hear :)
18:29:27 <MarkSmith> We also reviewed boklm's changes for #13324 and we spent a lot of time on non-Tor stuff.
18:29:40 <MarkSmith> This week we plan to do the updater testing I already mentioned and help with any urgent ESR31 issues.
18:29:48 <MarkSmith> We also plan to review deliverables from our current contract and get feedback from Mike on priorities.
18:29:53 <MarkSmith> That's all for us.
18:31:19 * boklm can go next
18:31:53 <boklm> last week I made the update_responses script generate incremental MAR files and opened ticket #13324
18:32:23 <boklm> 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 <boklm> 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 <boklm> 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 <boklm> I also plan to spend some time looking at Tor Messenger build process
18:34:07 <boklm> that's it for me
18:35:41 <mikeperry> 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 <boklm> mikeperry: ah yes, I can do that
18:36:50 <mikeperry> 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 <GeKo> 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 <mikeperry> oh, and were you able to get an mbox test working for #13020?
18:38:28 <MarkSmith> Is that a separate sha256sums.txt file for incremental mars or all mars?
18:38:34 <mikeperry> GeKo: yes
18:38:40 <GeKo> good
18:38:42 <mikeperry> MarkSmith: I think just the incremental mars
18:38:51 <MarkSmith> mikeperry: OK
18:38:56 <mikeperry> since they need extra magic and a previous release to build
18:38:58 <boklm> mikeperry: yes, I have an mbox test, I need to run it on 4.0 nightly
18:41:21 <boklm> 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 <mikeperry> ah, yes, probably
18:42:13 <MarkSmith> 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 <isis> [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 <isis> s/80/200/ even
18:43:47 <mikeperry> MarkSmith: probably should be part of boklm's branch, too I think
18:43:58 <boklm> MarkSmith: I can do that
18:44:07 <MarkSmith> boklm: thanks!
18:45:07 <mikeperry> 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 <boklm> ok
18:46:47 <mikeperry> 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 <GeKo> yes
18:47:18 <mikeperry> but we can use it for 4.0.1 perhaps, if it seems to work out ok
18:47:24 <GeKo> sounds like a good idea to test them there to, first
18:47:25 <GeKo> yes
18:47:43 <GeKo> *too
18:48:12 <MarkSmith> The good news is that if applying the incremental mar fails, the complete mar should be used as a fallback.
18:48:41 <GeKo> yeah, "should" ;)
18:49:01 <MarkSmith> (We have seen that work with Tor Browser in the "lab")
18:49:10 <MarkSmith> Finger crossed....
18:49:14 <MarkSmith> Fingers too
18:50:13 <mikeperry> 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 <mikeperry> stuff with priority major we really want to try to get done in some form. stuff in normal probably can wait
18:52:34 <mikeperry> #13016 and #13025 need owners. I think #13346 is just a pref change
18:53:51 <MarkSmith> brade and I can take #13016
18:54:05 <MarkSmith> (assuming our updater tests go OK, we should have tme)
18:54:08 <MarkSmith> time
18:55:31 <GeKo> I think I can work on #13025 if nobody else is stepping up.
18:56:01 <GeKo> and, yes, #13346 should only be a pref change
18:56:17 <GeKo> I am not convinced about that "saves to disk part" yet
18:56:29 <GeKo> s/about/of/
18:56:30 <mikeperry> 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 <MarkSmith> What is our deadline/goal for getting all code changes in?
18:57:40 <GeKo> Thursday, I guess?
18:58:04 <GeKo> then we could have one nightly, or so, while rebasing
18:58:15 <mikeperry> 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 <mikeperry> ok
19:01:55 <mikeperry> anything else?
19:04:18 <mikeperry> ok, I think we are good then. let's hope all goes smoothly between now and next monday :)
19:04:49 <mikeperry> #endmeeting