tbb-dev October 2018

tbb-dev@lists.torproject.org

2 participants
4 discussions

Nightly rebase experiment proposal
by Arthur D. Edelstein 03 Feb '20

03 Feb '20

Hi everyone, Here's a plan for experimenting with moving Tor Browser from ESRs to mozilla-central. Why try this? There are several reasons I can think of: * There is no mobile Firefox ESR. In order to keep mobile Tor Browser secure, we would either need to constantly monitor for security fixes and apply backports. It will be simpler to follow the Mozilla release cycle. * Tor Browser will receive all security patches and security features from Mozilla, not simply those deemed important enough to backport to the last ESR. * Closer collaboration between Mozilla and the Tor Browser team will be possible, because everyone will be focused on the same codebase. For example, non-urgent patches can land directly on mozilla-central, bypassing tor-browser.git altogether, and those patches will be deployed to Tor Browser faster than they would have been on an ESR-only schedule. Mozilla will provide expert review of patches. Also, some non-urgent patches by Tor Browser may be written by Mozilla engineers. * The Tor Browser development process will be smoother and more gradual. Instead of rebasing and patch-fixing sprints ahead of each ESR, we can automatically rebase patches every night, and fix any patch whenever its rebase fails. (The total rebase effort should be approximately the same as before.) * Patches that frequently break because they live on "hot code" can be identified and uplifted. * We'll need to continuously monitor the mozilla codebase for new features that could harm privacy. That's potentially difficult, but by focusing on Mozilla's current work, we can hopefully stop patches that affect privacy before they land. Here's how I envision the new rebase process: * An automated script rebases all tor browser patches every night against mozilla-central, mozilla-beta, mozilla-stable and mozilla-esr. An email alert will be sent if the rebase of any patch fails. (I have a prototype script that does the basic rebasing -- it found that ~40/140 patches from our ESR-52 branch could be auto-rebased onto mozilla-central without any intervention.) * Any failed patches will need to be manually fixed up promptly so that the automated rebase can resume. * Diagnostic Tor Browser bundles will be built against the latest rebase branches. We can also run regression tests. So how do we ramp up this experiment? 1. 2018-1-1 to 2017-2-22: Rebase tor-browser.git patches manually on top of Firefox 59-beta. (We have to do this anyway.) 2. 2017-2-22 to 2018-3-13: Activate a script that rebases Tor Browser patches nightly onto mozilla-(central, beta, stable, esr). 3. 2018-03-13 to 2018-05-07: Create nightly Tor Browser bundle builds based on nightly rebases. At this point, we can evaluate whether we would like to transition to releasing Tor Browser alphas based on the mozilla-beta branch. Switching Tor Browser stable to mozilla-stable can happen sometime after that. How does this sound? Interested to hear what you think. Thanks, Arthur

7 12

November 7, 1900 UTC Security Control Redesign Sync
by Georg Koppen 30 Oct '18

30 Oct '18

Hi all! We thought about meeting at 1900 UTC next Wed (November 7) to hammer out the last issues for our security control redesign. Place is, as usual, the OFTC IRC network in the #tor-meeting channel. Please join us if you can! The current proposal[1] and a summary of where we are and what still needs to be done[2] are good starting points to get up to speed in case you missed previous discussions. See you there, Georg [1] https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-secur… [2] https://trac.torproject.org/projects/tor/ticket/25658#comment:45

1 0

Moving our meeting time to 1900 UTC
by Georg Koppen 30 Oct '18

30 Oct '18

Hi all! Summer time is about to end (and ended in Europe already), so we move our meeting time accordingly to 1900 UTC starting from next week on Monday (Nov 5). The location stays the same, though: OFTC IRC network in #tor-meeting. Georg

1 0

Tentative roadmap up to (and including March 2019)
by Georg Koppen 15 Oct '18

15 Oct '18

Hi! Below comes the link to our tentative roadmap: https://pad.riseup.net/p/tbb-roadmap-2018-19 I still need to talk to the network-team to make sure we are on the same page with respect to items they have on their radar and which we need. In brackets are potential sponsors for work we want to do (some of this is currently under submission). I assigned folks to work on particular items but that's not finalized yet. Please speak up if you'd like to have different assignments. The work for Q1 in 2019 is not as detailed yet to give us more flexibility and pick up more important stuff in case it emerges. I hope we can finalize the roadmap this week and think we should talk about it in our meeting later today. Georg

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev October 2018