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