18:01:09 #startmeeting tbb 18:01:09 Meeting started Mon Oct 20 18:01:09 2014 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:27 <- is lurking, stayed up after all! 18:02:17 * sherief is here 18:02:40 hi 18:03:08 so last week was the 4.0 release. it had some bumps (last minute SSLv3 disabling builds), but seems to be OK? I heard whispers of a crash report on Windows, but I was consumed by my meeting with Roger. eager to hear how everything has gone since then 18:03:59 I think that's it for me for TBB 18:04:04 There are a lot of complaints in the blog comments. 18:04:37 I can talk about the help desk 18:04:48 no one uses the tor binary from our bundle builds to run relays right? 18:04:52 The Windows crash (#13443) is the biggest one 18:04:57 are there any common themes? 18:05:00 ah, ok 18:05:19 Some people do not like the UI change (due to FF Australis) 18:05:38 Other people are annoyed by a variety of smaller bugs. 18:05:45 MarkSmith: actually #13472 is more frequent on the help desk than #13443 18:05:52 And then there is #13443 18:06:03 sherief: OK 18:06:04 (and does tor-browser use an openssl compiled with no-sslv3?) 18:06:17 no 18:06:24 ok 18:06:26 tor-browser does not use openssl 18:06:36 I mean the browser 18:06:59 and the openssl we ship does not have it disabled 18:07:49 ok 18:08:32 MarkSmith: the new UI doesn't look like firefox a lot which is good but why did the bookmark shortcut had to go? 18:08:40 the one between the address and search bars 18:08:44 asking because there's .9-rc now 18:09:14 sherief: it and the home button got moved into the menu bar 18:09:36 the toolbar struck me as way too cluttered and confusing 18:11:01 (the menu bar is the thing that looks like a sewage grate) 18:11:28 menu button, I guess 18:11:28 hamburger menu is a nicer term for it ;-) 18:11:34 ok. TB 4 now has an updater but no one will really know it's there #13406 18:12:24 * sherief forgot to change the ticket subject 18:13:20 In light of #13432, we probably don't want to make the updater more prominent yet. 18:13:46 re 18:14:51 I agree long term that the two notifications should eventually be the same action 18:15:57 but I am not sure we want to do it yet. I'd like to have MAR signing and HTTPS cert-leaf pinning first 18:16:51 * GeKo nods 18:19:23 oh, after everyone is finished giving their update, we should discuss what we want in the alpha series 18:20:17 how is the key/signing migration going? 18:20:18 which I punted on by just updating them to 4.0 for now, but we can include more things for our sponsor deliverables 18:21:45 we're not sure how we want to handle that. like GK, I'd like to have multi-key signing of sha256sums.txt be the way, but informing users of how that works seems problematic 18:23:02 it seems we need to pospone our plan as the support people made some strong arguments for the world not being ready for that yet :( 18:23:08 *postpone 18:23:22 (i.e. the sha256sums.txt signing) 18:24:02 so the current options are a role key shared somehow by a bunch of people or a signel key again 18:24:07 I think a role key signed by the signers is probably the best short-term fix. long-term it would be cool if gpg could verify sha256sums & signatures at the same time 18:24:14 buuut... 18:24:34 and yeah I guess the issue with any new key is that you're gonna get a bunch of fake ones like me 18:25:05 anyway, let me know if there's anything I need to do to help bootstrap trust or anything 18:25:09 can't we just have mozilla include helix as a CA 18:25:23 haha 18:25:32 certificat authoritah 18:26:06 so, if there is no better option showing up I'd vote for a role key as this at least resolves one bottelneck we have 18:26:18 yeah, we'll need to sign the new key with yours, probably, and we'll need to figure out some manageable but secure way to share it 18:26:30 crazy idea. 18:26:39 we will also need to do the same with the MAR signing key, too though 18:26:58 if gpg compatibility is the goal: generate a primary key in some secure way, with several signing subkeys. Give everybody who should be in the role one of the subkeys? 18:27:08 u wot 18:27:17 haha 18:27:18 nevermind 18:27:24 yes, that is one option we were discussing 18:27:34 u wot is the best reply ever to that. web of trust forever. 18:28:11 no, he pinged me lol 18:28:28 anyway I like nickm's idea 18:28:56 u wot m8? fite me irl 18:29:55 nickm: you can have key revocation thingies for just subkeys right? 18:30:13 yeah 18:30:20 plenty of people expire their subkeys on a yearly basis 18:30:27 or shorter/longer 18:30:38 how to i disable being pinged when you guys say subkeys 18:30:43 thought that was just the exp date and not a revokation 18:30:52 subkeys: you can't, just deal with it 18:30:57 subkeys: /nick keyssub 18:31:00 name yourself subkeys_ ? 18:31:16 eh, fuk it 18:31:21 Yawning: hm true, I guess I hadn't really considered the difference 18:31:39 I mean, it's essentially revoked at that point, but I didn't check about rev certs 18:32:26 oh gues with the masterkey youdon't need a revcert 18:32:36 since you can use revkey/revsig 18:32:43 ah true :) 18:33:21 who gets to make the trip up to mount doom to try to generate this key securely? and then also get it to people... 18:33:45 that is the question :) 18:33:57 so, random.org passed through md5 as my entropy source is good enough right? 18:34:04 :P 18:34:38 that's probably a conversation more appropriate for email or something anyway 18:34:40 I am not sure I have the GPG-fu to selectively add/remove subkeys for all the different subkeys on this role-key.. 18:34:44 yeah 18:34:51 maybe we can also include in each release a keyring file that people can use to check the next release ? 18:34:59 but plus loop me in :) 18:35:14 Detached signing subkeys were nontrivial last time I tried. weasel had some scripts that changed them from "impossible" to "very hard". 18:36:20 we should probably get back on track 18:36:36 and settle this over email/trac 18:36:42 * nickm shuts up, but requests an invite to the conversation when it happens 18:36:43 #13407 is the ticket, btwe 18:38:08 who wants to give the next update? 18:38:30 did sherief finish help desk issues? 18:38:48 good question 18:38:49 MarkSmith: pretty much 18:39:03 nothing else for me. 18:39:17 * MarkSmith can go next 18:39:29 everything is on trac and I will keep you all posted 18:39:30 Last week Kathy and I tested the updater with the 4.0 candidate builds (and with 4.0-alpha-3 updating to 4.0). 18:39:40 We posted a patch for #13301 (needs review). 18:39:55 We briefly discussed the possibility of a UX mini dev meeting (January 2015?) with mrphs: https://trac.torproject.org/projects/tor/wiki/org/meetings/2015UXMiniDevMeeting 18:40:14 We were away for several days at the end of the week and are now starting to triage various TB 4.0 bugs. 18:40:24 This week we plan to continue triage and help fix the most critical TB 4.0 issues. 18:40:32 As a team (including support), we probably need to prioritize and divide up the bugs. 18:40:42 That's all for us. 18:42:29 MarkSmith: how to do you want us to prioritize bugs? 18:42:36 I mean where 18:42:46 I am not sure 18:42:56 In trac I think 18:43:17 is there a specific tag we should use or we should create a new one? 18:43:42 It is not always clear how many people are being affected (hard to communicate, I know). 18:45:12 I am almost done with a tool support will use to vote on the frequency of issues maybe that will help support report to the TB team better since half of support aren't on irc 18:45:18 are we talking about usability issues here? I follow usability and tbb-usability tags. 18:45:59 Another way to look at it is that we will probably need to do a 4.0.1 release to fix #13443, so we should think about what else we want to fix immediately 18:46:05 tbb-helpdesk-frequent is the tag for issues that apear frequently in support mail and on the blog 18:46:38 usually also with tbb-usability, but not always 18:46:58 but we don't right now have any way to guarge relative frequency or severity of those bugs 18:47:20 MarkSmith: I agree. 18:47:35 gauge 18:48:49 here is what I did: 18:48:54 from the help desk side we will have a tool for that, hopefully next month it will be deployed 18:49:13 Lunar^:^ 18:49:26 I was helping with the release and its fallout. 18:49:33 shall we drop tbb-helpdesk-frequent and use tbb-usability or even tb-usability then add frequent tag if needed? 18:50:20 then I more or less postponed the test for the issue in #13027. 18:50:46 and I spent a good deal with analysing #13443. 18:51:14 It seems we hit a bug in Mozilla's code when compiled with mingw 18:51:42 I am currently bisecting which itself is a PITA. I hope can get results ASAP. 18:51:50 *we 18:52:29 this week I'll continue doing this and will finally resume my work on #9387. 18:52:38 that's it. 18:53:07 awesome. thanks for working on #13443 18:54:32 * arthuredelstein can go next 18:54:54 Last week I finished up patches for #11955. 18:55:08 Then I did a round of revisions in attempting to get my patches from #3455 into Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=122752 and https://bugzilla.mozilla.org/show_bug.cgi?id=436344). 18:55:29 I reported #13640 and wrote a patch for it, and backported a patch for #13033. 18:55:50 This week I'll work on trying to submit more of our patches to Mozilla. 18:55:59 we are close wrt bug 436344, nice! 18:56:12 Sorry, should be #13460 18:56:38 I hope so :) 18:57:17 that's it for me 18:57:31 * boklm can go next 18:57:56 this week I have been mainly working on tor-messenger 18:58:05 I added a patch on #13324 which should now be ready for review/merge 18:58:38 I made a patch for tor-browser-spec to document version numbers: http://paste.fedoraproject.org/143588/14138286/raw/ 18:59:02 I also started a patch for #13015 but it's not finished 18:59:23 This week I'll try to do #13015 and #12222 18:59:38 that's it for me 19:01:02 * isis can go whenever 19:02:35 last week i worked on #12193 and finished the IDP implementation by Monday/Tuesday 19:02:55 except to fully test its interoperability with other Persona servers, it would need a domain name and "valid" SSL cert 19:03:29 which i began doing until my bank blocked my card a lot 19:03:53 i haven't checked yet, but i probably have the stupid cert and domain by now :/ 19:04:04 i found other problems with Persona 19:04:12 it is not "decentralised" 19:04:16 not at all 19:04:41 unless you count users being sent to whichever IDP the site feels like sending them to to log in 19:04:59 the default is always hardcoded to login.persona.org 19:06:12 so what would happen in our case is Alice goes to Wikipedia, who sends her to login.persona.org who passes along stuff to persona.tpo 19:06:14 (time to write Tor Plursona with blackjack?) 19:06:22 :) 19:06:42 * isis bans the word plur 19:06:50 :( 19:07:35 there probably are different behaviors when using the built-in navigator.mozId vs the fallback script implementation. and then I bet it also behaves differently depending on if you have any current, valid identity certs installed 19:08:16 yes, but `include.js` which Persona-enabled sites are supposed to use is hardcoded to use navigator.id 19:08:40 and using navigator.id is not possible at the same time as using navigator.mozId 19:09:21 how many sites out there currently use include.js already? 19:09:24 that behaviour is possibly a bug, i suppose, since the navigator.id one was supposed to be a "fallback" 19:09:29 and could they be conned into changing it? 19:09:32 :P 19:10:04 Yawning: i found two: 123done.org and bugzilla.mozilla.org 19:10:49 "we fixed the bugs in include.js, use includeInstead.js from now on"? 19:11:26 also note that, because the server it's contacting is hardcoded, the a site which wants to test against the development version of Persona must use login.anosrep.org 19:11:37 its supposed to check for navigator.mozId and use that instead of the fallback JS if it exists.. 19:11:59 no, it is one or the other 19:12:34 i wrote an error handler on https://93.95.228.166/index.html to see if you have nav.mozId 19:12:45 and tested it a lot 19:13:12 also testing against beta.123done.org 19:13:54 anyway, i suppose what i wanted to say is that we should all come to an agreement on how to proceed with this 19:14:05 maybe not now, it could be a different meeting 19:14:18 but soon is good 19:16:10 isis: could you update the track ticket with all the things you found which would basically be blockers for us/bad for the persona system itself? 19:16:23 GeKo: yes, of course 19:16:42 i should have done that last week, i guess. i'll do it today. 19:16:51 thanks 19:17:42 yeah, it sounds like this thing is a tangled mess.. we should probably also check with #identity on irc.mozilla.org about that navigator.id issue.. that seems super broken that it doesn't handle using navigator.mozId properly if it exists 19:19:08 I kind of have stuff to report, but it's sort of minor 19:20:09 tldr, working on making flashproxy easier to use for people by reworking our nat traversal helper with the power of love, magic of friendship, and golang. 19:20:26 see #13338 for details 19:21:07 (and afaik nothing further is required of me on the obfs4 front, if that is not the case let me know) 19:21:56 the helper I wrote should be trivial to integrate into our deterministic builds, though go lang binaries are kind of big 19:22:49 (python was briefly considered and ruled out because py2exe makes me really sad) 19:23:28 that's all the tbb relevant stuff I have 19:28:13 mikeperry: they seemed to have no idea what i was talking about in #identity when i checked 19:28:54 mikeperry: and finally in #developers on irc.mozilla.org florian answered to say that i needed a pref to enable navigator.mozId 19:29:19 hrmm. perhaps they need a demo case that shows them what you're trying to do, but I guess that is blocked on getting the domain + cert 19:29:20 perhaps it is the pref that causes the two to be incompatible 19:32:01 Yawning: do you know if there is a way to tell go/gccgo to compile multiple binaries at once in a way that they can share common things? 19:32:32 "complain to the developers to support shared libraries" 19:32:50 afaik, there isn't a way 19:32:51 thaht would be really helpful 19:33:03 yeah no kidding 19:33:24 it concerns me a bit that we get more and more go things AND there is no shared library support 19:33:45 hmm... i remember during my brief excursion into making a go crosscompiler a month or so ago, that it seemed there might be a way... 19:34:09 I mean, should I focus on making tor-fw-helper's unmaitainable dependencies not suck? 19:34:20 but that it would likely involve moving all the packages you wanted into a new package, and renaming all their "main"s to "whatevermain" 19:34:28 I did it this way because at least it's easy to corss compile deterministcally, and it's safe 19:34:49 uh wut. that'll still lead to gigantic executables >.> 19:34:57 yeah, I wonder if its possible to make a go busybox-like mutant combined binary 19:35:15 at least they would all share the static runtime then.. 19:35:20 probably a build nightmare though 19:35:39 oh I see 19:35:41 that's basically what i wanted, but i couldn't get it to happen 19:37:10 could, but not sure if I'd want to 19:37:38 would require renaming all the main packages, renaming the main functions so they're exported, and writing a stub loader 19:38:49 anyway, if go-fw-helper isn't useful, then I'll occypy my contract-limbo time with something else :P 19:39:12 I have not said that it is not useful :) 19:39:19 anyway, Yawning, no, fixing go is probably not your job, i was just curious if you knew some secret sauce i was supposed to use, e.g. "oh yeah just setenv GCCGO_COMPILATION_TYPE='fubar' and magic you get a pony and some special binaries" :) 19:39:39 I wish ;_; 19:39:42 it seems super-useful. we've always been a bit afraid the the C version, IIRC 19:39:57 more the libraries yeah 19:40:07 dcf and I talked about this at paris, and i finally got around to it 19:40:28 flashproxy needs minor changes but I'll do those shortly 19:41:30 (dunno if a upnp stack that someone else wrote in C is more or less scary than one I wrote in a drunken fit of rage, but, not my decision :P) 19:41:36 I wonder if in the meantime we can do tar hacks to get all the go binaries to be sequential in the tar archive, so thst xz has a better chance of seeing them in the same compression window 19:42:09 though I guess we also need that for dmg and nsis, too, and who knows if that will even help much 19:43:30 too bad strip fucks up go binaries on certain platforms 19:44:47 so, wishlist for the next alpha? 19:44:59 I think obfs4 should be in it 19:45:06 ^ 19:45:22 yeah 19:45:27 I've been making a list during the meeting 19:45:31 here's what I have so far: 19:45:32 maybe flashproxy with this helper, have to ask dcf/infinity0 abou tit 19:45:43 becasue it would boost usability considerably 19:46:20 #13301 (and next stable), #13460 (and next stable), #13033, #11955, #13019, #12903, #13356, #13324 19:46:33 that reminds me, i was convinced by karsten that i should try to convince y'all that we only want to use public bridges in bundles 19:46:35 and possibly arthuredelstein's SOCKS isolation patches, if those are ready? 19:47:51 Mozilla reviewer has pointed out an issue with websockets in the SOCK patches. So I'll try to fix that today, and then I think they'll be ready 19:47:53 isis: yes? 19:48:08 the list is public and in git/the bundles anyway, why are they sekrit? 19:49:03 should i make a ticket for going through the current bridge list and telling the operators that they either need to give their descriptors to Metrics (via BridgeDB and the BridgeAuth) or else be kicked out of the cool kids club? 19:50:02 shall I make a tag for alpha stuff? tbb-4.1-alpha? tbb-4.5-alpha? (do we want to call it 4.1 or 4.5?) 19:50:26 we need a maint-4.0 branch I think, first 19:50:30 due to obfs4 19:51:00 4.5 sounds good 19:51:14 * isis laughs at the crazy version numbers 19:51:25 isis: yes, and Cc kpdyer, yawning, asn, and (maybe) dcf (though I think it doesn't matter for flashproxy and meek, since they already do metrics reporting?) 19:51:31 isis: imo yes, becasue better pt metrics is part of the sponsor s thing 19:52:22 ok 19:53:44 meek users seem to have gone up 5-6X since the 4.0 release: https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&start=2014-09-22&end=2014-10-20&transport=meek#userstats-bridge-transport 19:57:18 Also, for TB 4.5a1, we may want to try an incremental update from 4.0 (could be exciting). 19:57:27 arthuredelstein: which ticket(s) will your SOCKS patches end up in? #3455, or #6733, or both? 19:58:15 MarkSmith: yeah, I am hoping #13324 will let us do that, though I haven't looked at the patch yet 19:58:51 mikeperry: we should have #13356 in the stable builds already, no? 19:59:15 Oh, yes, I see you have #13324 in your list. For some reason trac.tpo is unresponsive to me so bring up ticket descriptions is impossible. 19:59:28 bringing up too 19:59:32 GeKo: yeah, stale ticket from an older ticket list I had in my TODO file. woops 19:59:33 Trac not responding to me either at the moment 20:01:24 trac was loading extremely at times last night, too 20:01:31 extremely slowly* 20:03:24 ok, well when trac comes back I will tag all those tickets, and we can branch for maint-4.0 also 20:05:11 what is our timeline for the alpha release? I wonder whether we should get a first version of a fix for #9387 squeezed into it due to deliverables 20:05:48 Hi, is the trac instance down? It takes more than a minute for every page load. 20:06:09 Right now I'm reading tickets on archive.org 20:06:27 GeKo: Another reason to squeeze that in would be to get feedback from testers and support people (and alpha users) 20:06:32 UI feedback, etc. 20:06:50 loic: it was flapping a minute ago for me too, with 1min loads, but it's fine now 20:06:59 GeKo: yeah, I think we can wait for that, and just test nightlies in the meantime 20:07:02 Based on the 4.0 release, I am reminded how much some people dislike change ;) 20:07:20 yes, sure. that's always good :) although my main motivation is not missing the deadline atm 20:07:22 loic: please aim your cannons at the baddies, not us please. :) 20:07:34 GeKo: right; makes sense. 20:08:08 mikeperry: #3455 will have 3 patches for SOCKS domain isolation. Then the Tor circuit UI, whenever we feel like adding it, will be #8641 and #8405. 20:08:13 isis: hehe it's my actual first name ;) 20:09:02 to submit a patch > attach file in the ticket attachment section, correct? 20:11:30 loic: yes, that works great, or you can include a link to a publically clonable git repository and a branch :) 20:13:07 cool thanks. 20:13:20 arthuredelstein: ok, I will tag #3455 with tbb-4.5-alpha then. I figure it will probably be useful for development and testing to have the APIs we need in a build before the UI is ready anyway 20:14:09 OK, sounds good. 20:15:49 ok, anything else? 20:16:21 just an announcement: I'll be afk next monday-wednesday inclusive 20:17:35 ok. if you make progress on anything to be merged by then, tag it with MikePerry201410R aand update the tickets, and we can discuss it ourselves at the meeting 20:17:53 sure 20:19:21 ok. I think that wraps us up then. thanks everyone! 20:19:29 #endmeeting *baf*