18:02:22 #startmeeting tbb-dev 18:02:22 Meeting started Mon Mar 30 18:02:22 2015 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:22 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:49 arthuredelstein: Or Karsten? Not sure. 18:03:14 arthuredelstein: did you los the content or do you still have it? 18:03:29 I still have it. I just keep getting rejected. 18:03:42 this meeting is on the Tor Browser, yes? 18:04:15 * isabela would like to give an update at discussion time 18:04:22 yes, let's get started 18:04:27 isabela: ok sounds good 18:04:52 Last week, I cleaned up #13375 based on GK's testing and review, closed #13766 and then went with #15482 instead, and went on a bit of a merge rampage trying to get things in for 4.5a5 (in the process merged some things I shouldn't have in the rush - thanks for everyone who was paying close attention and caught mistakes). I then wrote the changelog for 4.5a5 and then GK and I went through an agonizingly 18:04:59 long series of builds (5 or 6 depending on how you count) trying to get everything right. 18:05:16 However, all-in-all I'm very happy with TBB 4.5a5, and everyone derserves thanks and congratulations for their hard work and dedication to getting everything ready in time. I really do think that TBB 4.5 will be the most user-friendly release we've ever made, and I look forward to seeing our download and update ping counts rise over the coming point releases. 18:05:16 Sebastian: Probably it's best if we discuss after the Tor Browser meeting. 18:05:34 arthuredelstein: #tor-project 18:05:40 This week I plan to finish up the TBB releases for Tuesday, write the monthly status report, and go through the TBB-4.5 and monthly tickets to determine our plan for 4.5-stable and the rest of the month. 18:06:03 GeKo and I have some final coordination to do to decide who takes what part of the releases for Tuesday 18:06:07 but that's it for me for now 18:08:26 * mikeperry wonders if he was too last-minute in the adjustment of the meeting time for EU Summer Time. Is anyone else around? ;) 18:08:40 huh, meeting 18:08:43 * boklm is around 18:08:44 hehe 18:08:52 i am, now 18:09:07 * mcs is here. 18:09:26 yay! 18:09:39 * mcs can go next 18:09:48 This past week, Kathy and I fixed #15406 and also prepared a fix for #13576 (needs to be reviewed). 18:09:57 We did some miscellaneous bug triage, e.g., for #12682, #15473, and #15502. 18:10:11 We reviewed GeKo's fix for #7255. 18:10:20 And we did some testing of the TB 4.0.6 and 4.5a5 release candidates. 18:10:27 This week we will work on #15491 and help with other remaining 4.5 issues. 18:10:33 Also, Kathy and I will both be away from the office late this week and the first part of next week. 18:10:41 That's all for us. 18:13:11 mcs: ok, great. I am actually planning to send everyone an email telling them that we should all try to take a breather and a few days off after 4.5a5. it was a bit intense (esp with pwn2own and the late Mozilla tagging) 18:15:34 * boklm can go next 18:15:43 mikeperry: I appreciate you looking out for everyone. Don't forget to take a breather yourself. 18:16:02 This past week I have been mainly working on tor-messenger stuff 18:16:04 Other than that I updated the security sliders tests for the latest torbutton changes (the testsuite with those changes is running on 4.5a5 at the moment) 18:16:10 And started looking at the test page for #15511 18:16:23 This week I'm planning to add tests for #15511 and #13375, and look at having some nightly builds 18:16:44 that's it for me 18:17:01 boklm: what happened to the virus total thingy? 18:17:16 GeKo: hmm, I need to check 18:18:12 hre is what I did: apart from the release related things I worked on: 18:18:16 *here 18:19:28 #7255, #15460, #6503 and #15510 18:19:49 I spent quite some amount of my time with testing #14429, #13755 and #13019 18:20:09 and I thought a bit about #4100 and #15502 18:21:15 this week I plan to work on getting the release out, update related documentation (#15252 is in the review queue) 18:21:43 and give the alpha more testing (this already uncovered #15510) 18:22:14 I planned to look at our roadmap to map the bugs to a sponsor 18:22:20 not sure if I get to that 18:22:26 that's it for now 18:23:34 * arthuredelstein can go 18:23:38 This past week I worked on patches for #13019, #15460, #15472, and #14429. I also did code review for #13766. And I made some revisions and exegesis for my patches in #13670. This week I'll work on further improvements for #14429 and #15474 and maybe #15239. 18:24:11 that's it for me 18:27:08 so a while ago we disabled site-specific zoom 18:27:25 however it appears that it still remembers zoom for the current tab when you change sites 18:28:59 one option that might be simpler for #15474 is just make sure that zoom is reset upon navigation to a new site. Not ideal for people who rely on zoom to read, but it may make it less of a linkability risk and may be a simpler change if #15474 proves to have lots of OS-dependent edge cases like #14429 did 18:29:35 That's a good point. 18:30:10 One tricky issue is that if we adjust dimensions to handle zooming on one tab, then the dimensions are wrong on another unzoomed tab. 18:30:13 I have also noticed the same edge cases with #14429 that GK has, btw. the alt key is an especially irritating one :/ 18:30:21 arthuredelstein: ah, yes 18:30:55 Yes, I'll be looking into the alt key soon 18:31:44 One possibility would be to have a global zoom setting only. All tabs and windows zoom in and out together. 18:32:29 I wonder if we would get further by trying the C++ patch road for #14429. I fear we end up in the same mess as we did when implementing the resizing on start-up feature. 18:32:38 sounds like an option, but I wonder if that will make #13875-type things worse 18:33:31 (the global zoom idea) 18:33:33 GeKo: Yes, I think it's worth considering that for addressing at least some parts of the problem. 18:34:35 mikeperry: Definitely something to check. 18:35:32 the global zoom option sounds like a good idea to me 18:37:23 GeKo: your #4100 experiment is very interesting. I wonder if that is a side effect of arthur's nsIChannelProxyFilter implementation. prior to our use of that, the HTTP stack would see that an already-available HTTP keep-alive connection was open, and send the request down it. since the connection was already open, no SOCKS handshake was involved 18:37:36 but perhaps there is logic that causes it not to do that if the proxyInfo has changed 18:38:04 which would be great news for SPDY and for HTTP/2, if it is the same there 18:38:10 yes, I thought so, too 18:38:39 I actually thinkg this is due the nsIChannelProxyFilter 18:38:56 I have not had time to look at it closer though 18:39:10 *think 18:39:29 ugh, s/due/due to/ 18:39:34 the ability to raise the kee-alive would be a huge help for etherpad-type sites, and for google docs/gmail/webmail in general 18:40:38 I am frequently disconnected from riseup/etherpads while editing them, and I suspect that some combo of our low keep-alive and the pre-#15482 behavior was to blame 18:41:18 we might want to look at it then for 4.5 might be some low-hanging fruit 18:42:17 and would fit pretty well to the usability boost this release comes with 18:42:47 yep, already updated the tags on the bug :) 18:44:37 ok, so I think either isabela should go, or we should discuss wrapping up+signing+posting 4.5a5 18:44:41 maybe isabela first? 18:45:15 sure 18:45:55 is just a quick note about roadmaps - I am working with all teams trying to keep the roadmaps updated and reflecting the team's work. 18:46:18 I wanted to ask the TBB team to review what you added for april and to let me know if there is any blocker or dependencies 18:46:42 thats it - does any one has questions or comments? 18:47:12 (our roadmap is at https://trac.torproject.org/projects/tor/wiki/org/roadmaps/TorBrowser for people who were just looking for it now) 18:47:27 tx mikeperry 18:47:59 the upstream deliverables for TBB are summarized here: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorU/TorBrowser 18:48:13 but those are over 2 years 18:48:20 [A 18:49:42 What's the schedule for the forthcoming 4.5 releases? Will 4.5 have a beta period? 18:50:00 no it will be stable in 2-3 weeks 18:50:36 we don't need beta periods ;) 18:50:40 OK. And once it's stable, that means all new patches apart from bugfixes go into a 5.0-alpha branch, correct? 18:50:48 we need to decide how we want to handle update channels. ideally, we'll keep the alpha users on an alpha channel somehow and also update 4.0 users to 4.5 as a stable channel update 18:51:09 I am not sure if we want to auto-update 4.0 users to 4.5 for this first release in 2-3 weeks though. I think not? 18:51:15 arthuredelstein: yes, that's usually the case 18:51:28 unless there are things effecting stable as well pretty badly 18:51:31 so that would make it more of a "soft" launch 18:52:08 For the 5.0-alpha, we'll need to have rebased to ESR38, right? 18:52:24 If we do not auto update people to 4.5 some will wonder why not… but a soft launch might be safer. 18:52:25 I'l need to start working on that very soon then! 18:53:08 arthuredelstein: good question. 18:53:48 I think, no. 18:54:00 (fwiw, we will probably ship 4.5-stable in Tails 1.4, scheduled for 2015-05-12) 18:54:20 but the switch is happening in the 5.0 alpha series hopefully 18:54:21 I don't see a reason why the very first 5.0-alpha needs to be rebased on FF38esr 18:54:35 Ah, OK. That makes sense. 18:54:40 we should be careful about diverging torbutton and tor launcher strings for as long as we can 18:54:49 so we can keep taking translation updates in 4.5 18:55:18 mikeperry: what do you mean with "soft launch"? 18:55:55 I thought we build a 4.5 say in 2-3 weeks and then update people coming from 4.0 to it. 18:56:47 the "soft" part is if we auto-update the 4.0 people right away or not 18:57:06 since it won't be timed with a Firefox security release (we hope), we won't absolutely need to update people 18:57:50 which will give us some time to see if there are serious problems for some segment of the userbase with 4.5 18:57:54 ah, okay. 18:58:30 then I am in the "soft launch" camp, too, I think 18:58:49 Since there are some bugfixes that will need to happen before the 4.5 stable release, I wonder if it would make sense to have an extra 4.5-alpha release in ~2 weeks. Not sure how difficult that is, though. 18:59:22 With respect to the updater, we should be able to update alpha channel users to 4.5 stable but have them remain on the alpha channel. But we talked about this before and maybe there is some reason that won't work correctly? 19:00:03 (that's a rhetorical question; Kathy and I can do some testing) 19:00:18 (but I think that is what Mozilla does with Firefox) 19:00:26 I think we did the same thing with 4.0, did not we? 19:00:29 (for the beta channel) 19:00:38 Did it work ;) ? 19:00:38 and it worked IIRC 19:00:51 OK. I think it did. 19:01:09 ok, yes, I vaguely remember talking about this before and you saying it would work out. that sounds good 19:01:51 arthuredelstein: another alpha, no, I don't think so. 19:02:32 Fixes will need to be carefully reviewed and tested as much as possible by us, I think. 19:02:40 armadev: So uh 19:02:42 that bug 19:02:51 def is reproducable 19:03:25 Mar 30 19:02:28.000 [err] tor_assertion_failed_(): Bug: ../src/or/onion_tap.c:58 19:03:27 : onion_skin_TAP_create: Assertion pkbytes == 128 failed; aborting. (on Tor 0.2. 19:03:29 7.0-alpha-dev d2023c8979192654) 19:03:36 GeKo: mcs: OK! 19:03:36 sigh 19:03:50 we can also decide to auto-update 4.0 users at any point after the 4.5 release. that canjust be a function of if/when we publish the new update manifests 19:04:03 yes, sounds good 19:05:10 I wonder about the load we put with this strategy on our infrastructure, though 19:05:31 are we assuming that a great deal of users is still staying on 4.0? 19:05:51 does it matter? 19:06:34 we should ensure we have incrementals for a couple of releases, I think? like we did with 4.0.6 (we made incrementals for 4.0.4->4.0.6 and 4.0.5->4.0.6) 19:06:57 Yawning: yeah I made it explode also here in a chutney :S ... 19:07:29 :( 19:07:46 wonder how yours compares with mine 19:07:47 mikeperry: yeah, I was more wondering about the soft launch strategy 19:08:02 Yawning: (#tor-project, TBB meeting ongoing) 19:08:18 (oops, my bad) 19:08:39 as we probably want to get the release notes widely circulated and all the people might start downloading the full bundle as they con't get updated 19:08:48 *don't 19:09:17 especially if we write USABILITY!11!! 19:09:40 can we advertize a recommended update that doesn't actually throw a popup or other notification? 19:11:09 what do you mean? 19:11:23 mikeperry: I am not sure but will check. Do you mean an update they can get if they do an update check themselves but one that will not be shown automatically? 19:11:35 If we do this soft launch, I think it will require a small change to the update_responses script to list 4.5 clients as "no update needed", so they are not proposed a downgrade to 4.0 which is the latest version on the channel 19:11:45 well I guess it wouldn't help in the common case, because the "Check For Update" menu wasn't added to Torbutton until 4.5 anyway 19:12:28 * isabela step out for food but ping me if you need any help from my side on organizing and keeping the roadmap updated 19:12:35 What is the worst thing that can happen if we do not do a soft launch? 19:13:00 boklm: ah, good point 19:13:10 I guess 4.5 is a bad release and we scramble to fix issues. 19:13:22 (worst case? not fun to scramble) 19:13:23 yes 19:13:40 I think we had that experience with 4.0 to some extent. 19:14:01 yes, but chances a relow we hit such a windows crash bug with 4.5 19:14:04 well, I think the real nightmare scenario is we break TBB 4.0 users somehow in the update, and they are then unable to update to a new release and have to all start with a new TBB download 19:14:31 Do we have any statistics about how many people are running the alphas? 19:14:51 Yes, not being able to update would be bad. 19:15:39 mikeperry: but that sceanrio is not prevented by the soft launch strategy 19:15:44 we can ask weasel. we're going to want stats for things like #15456 after we release 4.5a5 anyway 19:16:45 GeKo: it might, if the bug is present independent of if you use the updater to install 4.5 or download a full copy yourself 19:18:08 I see, I read "somehow in the update" as referring to our built-in updater 19:20:09 well, we can continue to think about this depending on how 4.5a5 goes, ad what type of fixes we add to 4.5.0-stable 19:21:27 in the meantime, how should we handle the signing for 4.5a5. we're now going to do the windows signing, yes? does that mean re-packaging the NSIS to sign everything inside it (all .exes and .dlls)? and then also the NSIS exe itself? or just the outer exe? 19:21:41 for #3861 19:22:31 the plan currently is only the NSIS exe to tet the authenticode thing going 19:22:38 *get 19:23:27 and Windows will be OK if the firefox.exe is not signed? does it track that a signed app installed it or something? 19:23:50 windows is fine with that as far as i can tell 19:24:24 not that I am aware of 19:24:37 weird 19:25:38 are there any tools to strip Windows sigs off of .exes? 19:26:04 I found some scripts and plan to check that tomoroow + update the doucmentation 19:26:07 for verifyability against the build sha256sums? 19:27:20 yes 19:28:00 ok, so I guess if you handle that, I will handle the MAR signing and individual package gpg signing? 19:28:34 and we leave the sha256sums.txt files with the original build hashes, and provide unsign instructions (I'm guessing using osslsigncode?) 19:29:35 re mar signing and package signing: you could but I can do that tomorrow, too 19:30:27 I thought I could get the 4.0.6 out around noon my time and you could take care of the 4.5a5 which would split the load 19:30:54 and yes, we leave the sha256susm.txt with the original build hashes 19:31:31 hrmm. how should we handle the .exe gpg signing? 19:31:37 I think we need to sign the signed exes there 19:31:45 yes 19:32:29 so I guess that means I just do the MARs for 4.5a5. and/or I handle 4.0.6? 19:33:31 I am fine with signing all the stuff and get 4.0.6 out and you do 4.5a5 modulo the signing 19:35:16 ok, so that means prep the blog posts and maybe copy your signed stuff into place tomorrow? 19:35:35 yes 19:35:49 I can do both blog posts. the 4.0.6 one needs to remind the 32bit OSX users this is their last release 19:36:22 sounds good: I do the signing + 4.0.6 and you the blog posts + 4.5a5 19:37:25 ok, and to clarify I am signing nothing for 4.5a5, just making sure everything is in the right place 19:37:35 yes 19:38:30 ok great, I hate signing. so much juggling stuff between offline computers.. so tedious. I was trying to be nice by offering to do some of it ;) 19:39:23 I had the same motivation :D 19:40:32 and the overhead is smaller if just one is doing the signing 19:40:33 cool, thanks. I think we're set then. I will get to work on these blog posts 19:40:44 yeah, you're right. 19:42:57 I think that's it for this meeting then 19:44:34 isabela: as for the roadmap, we're in good shape for all of the stuff through April I think (the 4.5-stable things). the mobile stuff with Nathan's name on it could use some coordination, but after we get 4.5-stable out 19:45:22 once 4.5.0-stable is out, we'll revisit the rest of these items and make sure they all have tickets and are more clearly specified 19:46:00 thanks mikeperry ! 19:47:00 alright, thanks everyone! 19:47:06 #endmeeting *baf*