18:29:34 #startmeeting Tor Browser Team Meeting, 03 February 2020 18:29:34 Meeting started Mon Feb 3 18:29:34 2020 UTC. The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:29:34 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:29:45 okay, hello everyone! 18:30:32 hi! 18:30:47 * sysrqb wonders if anyone else is here :) 18:31:10 * sysrqb finishes writing status on pad 18:31:26 hi! 18:31:30 hi 18:31:50 hi 18:32:04 * mcs is also here 18:32:27 woo 18:34:25 hello! 18:36:44 okay, let's see 18:37:07 sysrqb, if by any chance you prefer to ignore my bolded item and just reply by email whenever convenient, that's totally fine for me :) 18:37:53 (I assume I'm pretty far back in your queue of emails that piled up last week) 18:38:46 Jeremy_Rand_Talos: i was going to say that I saw your email but I haven't read it yet 18:38:49 :) 18:39:08 but that is one item for me this week 18:39:13 sysrqb, great, no worries. 18:39:22 i've now added it on the pad, too :) 18:40:31 okay, i don't see any other bolded items 18:41:35 the "future plans" discussion is for how we move from ESR the ESR traain to the Release train 18:41:54 and mostly updates from All-Hands related to that 18:42:24 I think we should have a separate meeting for any real "planning" we want to do 18:43:06 i guess i'll just talk at you all and give a summary of the meetings, but stop me if you have questions/comments 18:43:28 i'll follow up with a mail to tbb-dev@, too 18:44:02 everyone we spoke with at All-hands was supportive of our plan of moving to the release train 18:44:32 and they was willing to help us use Mozilla's infrastructure for automated testing 18:45:09 we'll need to work through the administrative details of this (because this will cost Mozilla money, so there will likely be limits) 18:45:48 but, in theory, this should be approved and it should make our lives easier 18:46:14 we talked about automated, periodic, rebasing 18:46:40 and we decided it makes sense that we rebase on top of mozilla-central and -beta 18:46:56 this will result in false-positives, in particular when we run our tests 18:47:13 because mozilla could land bad patches which are later backed out 18:47:38 but if we ignore mozilla-central, and we only look at -beta, then we lose weeks of time 18:47:58 where we could be alerted on upcoming breakage 18:48:25 and fixing breakage on mozilla-central will be much easier than fixing it on mozilla-beta 18:48:28 (upstream) 18:48:47 we'll need to experiment with how we handle failures 18:49:04 that'll just be part of learning and growing into this new process 18:50:50 mozilla are interested in helping us defend against proxy-bypass bugs 18:51:10 in terms of isolating rust code that makes network calls 18:52:20 they think it is possible to move all that functionality into a library which we exclude during our build 18:53:07 the C++ code is more problematic, but we can experiment some other ideas 18:53:47 i'll be talking with pili at the end of this week, and we'll walk through the timeline for all of this 18:53:56 Unless you've heard differently, I think the plan for rust networking stuff is different from a separate library 18:54:32 but, at this point, i think we can move onto the release train by July 18:54:48 tjr: oh, maybe i misunderstood 18:55:01 That was an option, but I think we found a better one 18:55:30 Rather, everything would stay in the same library, but we would redirect all networking functions to an abort-like function. Those redirctions wouldn't work for cross-language LTO, but Tor can LTO all the c++ code and not LTO the rust code. 18:55:41 Which is a slightly different configuration from firefox but we think that's okay 18:56:57 oh, i thought that was a potnetial option, but not-the-best 18:57:09 mostly because we'd rely on Mozilla maintaining this 18:57:17 because we don't have that expertise 18:58:00 "maintaining" meaning telling us how to do it or helping us do it 18:58:10 i'm not even totally sure what that involves 18:58:32 but if they think that is the best option, then that's fine with me 18:58:33 I think both options will be us (me?) implementing it. 18:59:04 okay, we can work through those details 18:59:09 The separate library option has some concerns; the redirect option seems the most safe 18:59:51 okay, thanks for clarifying that 18:59:58 Is there something we can do to make all engineers who work on Firefox aware of the proxy bypass problem (so it is less likely that new holes will be introduced)? 19:00:18 (or maybe there is already awareness) 19:00:22 mcs: yes, and mike raised that during the meetings 19:00:29 good :) 19:00:54 it is not currently something tht is a high priority 19:01:17 but we're hoping that as they develop their Firefox Private Network stuff, they will begin caring more about this 19:01:33 and it will become a higher priority 19:01:58 and we are using that argument to increase awareness of it 19:01:59 makes sense. also, if Firefox had a Tor mode it might be more important :) 19:02:16 yeah, that too :) 19:02:43 that idea is currently stalled, but not dead 19:03:41 i'm secretly hopeful that if we begin working more closely with Mozilla because we use more of their infrastructure and land more patches directly on mozilla-central 19:03:49 FWIW we have re-classified proxy bypass bugs as sec-high, which makes them elligible for a $3-$5 bonty 19:04:15 then we'll have more visibility and maybe we'll be more likely to make progress on that front 19:04:23 tjr: oh, nice! 19:04:28 is that a recent change? 19:05:14 A few moths ago 19:05:45 One of the members of the bug bounty committee had the idea, and checked with the product manager of FPN to see if they felt it warranted the classification. They agreed. 19:05:50 sorry if you mentioned that last week and I missed it 19:05:58 First person = me. Second person = Arthur. ;) 19:06:04 sweet 19:06:05 heh :) 19:07:07 okay, i don't think i have anything else to add in this summary 19:07:33 in short, we're talking with mozilla about using more of their infra 19:08:06 we'll probably target July as a goal for fully migrating to Release (still need to be confirmed) 19:08:28 how many update channels will we have for Tor Browser? nightly, alpha, release? 19:09:02 and we have a lot of details to work through, so i may start scheduling additoinal meetings for only discussing on specific detaisl 19:09:17 mcs: yeah, likely 19:09:30 maybe renaming s/alpha/beta/ 19:09:36 side comment: we should consider renaming “alpha” to “beta” or “early access” in the hope that more people will use it 19:09:39 but that's one of the not-yet-decided detials 19:09:40 ah, good idea :) 19:09:57 ha :) 19:10:11 sounds like a great idea :) 19:10:42 okay, any other quetsions or comments? 19:11:07 (if not, then i'll get back to working on my emails) 19:11:53 does anyone remember if there was some topic from last week that we wanted to discuss this week with more people present? 19:12:07 i'd like to kick off this migration this week, so i'll be sending details soon about how we can start that 19:13:27 i haven't read the backlog from last week's meeting yet 19:13:47 so that's part of my catching up this week 19:13:56 brade: I think that was something about the review process 19:14:25 boklm: thanks 19:15:06 we discussed about documenting the rewiew process 19:15:07 let's discuss next week when sysrqb and others are caught up 19:15:26 ok 19:16:16 yeah, i think the answer is that pili/boklm/me (and anyone else who wants to help) should assign prelimiary reviewers during the triaging process 19:16:27 but we can discuss this more next week 19:16:40 i've also been failing at triaging recently, so I need to pick that up again 19:17:13 okay I'll close the meeting now. thanks everyone! 19:17:18 #endmeeting