tbb-dev December 2018

tbb-dev@lists.torproject.org

11 participants
5 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

Reproducible Builds Summit
by Nicolas Vigier 18 Dec '18

18 Dec '18

Hello, I was at the reproducible builds summit last week. During the meeting there were discussions about various topics related to reproducible builds: - reproducible builds for various languages, filesystems and distributions - bootstrapping - rebuilders and user verification - software transparency I think the two most interesting discussions for me were about rebuilders and user verification, and software transparency. = Rebuilders and user verification = Some people from New York University have been working on a framework called in-toto which can be used to verify before installing a build that it has been reproduced by a number of trusted builders: https://in-toto.io/ They have implemented some prototype for Debian. Here is how it works: - some independent organisations are running "rebuilders". Those rebuilders fetch new Debian source packages and rebuild them. When the build is finished they publish some json files containing informations about the source package, and the result of their build, and their signature. - apt is modified (using an apt-transport) so that before installing a new package, it connects to known rebuilders and fetch their build informations. If the build has been reproduced by enough rebuilders, then the package is installed. I think it might be possible to implement something similar in Tor Browser, maybe reusing some parts of their framework. = Software Distribution Transparency and Auditability = Benjamin Hof is working on tools for Software Distribution Transparency and Auditability: https://arxiv.org/abs/1711.07278 https://debconf18.debconf.org/talks/104-software-transparency-package-secur… He has implemented some prototypes to improve software distribution transparency in Debian, using a public log server which can be used to monitor the packages which have been distributed to users. I discussed with him how something similar could be done in Tor Browser. Here is how it could work: - we add a log server which can be used to cryptographically prove: * inclusion of an update in the log * append-only operation of the log - when we release a new Tor Browser version, we add checksums of the new mar files to the log. - when the Tor Browser updater receives a new update, it checks if the update is in the log, before applying it. If the update is not in the log, then the update is not applied. - independant monitors analyse the logs. They check that all checksums published in the log correspond to a known release. They can also check that the build corresponding to those checksums is reproducible. The log is public, so anybody can monitor it. The main improvement from this system is that it allows anyone to check that all the updates used by all users are reproductible builds, while today you can only verify that for one downloaded copy of the software. Nicolas

6 6

Fwd: Landing in 66: force opt-in to run extensions in private browsing
by Tom Ritter 18 Dec '18

18 Dec '18

I don't think this will be concerning for Tor Browser; aside from needing to set the appropriate bits for the bundled extensions. -tom ---------- Forwarded message --------- From: Shane Caraveo <scaraveo(a)mozilla.com> Date: Tue, Dec 18, 2018 at 3:39 PM Subject: Landing in 66: force opt-in to run extensions in private browsing To: <firefox-dev(a)mozilla.org>, <dev-platform(a)lists.mozilla.org> This is an FYI so you don't get surprised in the near future. The extensions API includes support for an "incognito" entry in the extension manifest where an extension may opt-out of running in private browsing windows. Chrome has since made that the default, and requires an opt-in by the user to run an extension in private browsing. We're playing a bit of followup on this, since we bypassed the feature during the crazy ramp-up for webextensions. The intention is to land this for 66, and a large chunk of it landed the other day. Extensions currently cannot make use of what has landed (though tests can and do). Extensions will continue to work as they previously did until we pref the feature on. The next part to land will be additional UI in about:addons[1] that allows the user to enable an extension for private browsing. A pref (off for now) will be introduced to enable this. At that point, you will be able to play with it, however there is more work to be done at the webextension API level. The pref will not be turned on until all necessary API modifications are completed. Assuming that everything goes according to plan, you will see this pref'd on during the 66 nightly cycle. At that point, all of your extensions, excluding system extensions, will stop working in private browsing until you enable those you want to work there. If you are curious you can look through the meta bug[2]. If you have questions, please feel free to reach out to me, mixedpuppy, on #webextensions irc channel or #add-ons on slack. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1511636 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1380809 _______________________________________________ firefox-dev mailing list firefox-dev(a)mozilla.org https://mail.mozilla.org/listinfo/firefox-dev

2 1

Torbutton and Tor-Launcher Webextensions
by Matthew Finkel 13 Dec '18

13 Dec '18

Hi all, The next steps for torbutton and tor-launcher will be migrating from the restartless pieces to webextensions. This will be a requirement for the next ESR, and it is already the situation with the current Firefox releases. Also, they must be system add-ons. Overall, we believe nearly everything torbutton and tor-launcher currently do can be accomplished with webextensions (assuming I remembered all the things they do). The key here is using a "Webextensions Experiment" for extending the Webextensions API for our needs. https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webex… This should be enough for interacting with the XPCOM services the extensions currently use. The one problem we will have is observing the profile-after-change topic. We'll likely need another Firefox patch so we can trigger the current functionality. The main reason we can't achieve this with webextensions is webextensions are run asynchronously, so a webextension won't block the browser start-up progress (needed for TorProcessService in tor-launcher, and parts of torbutton). In torbutton, we may be able to provide domain isolation using the webRequest.onBeforeRequest event: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/… On this event, we should receive information about the connection, including the ProxyInfo. I wonder if we can use the current implementation in torbutton and overwrite the ProxyInfo object we're given from the request with a new domain-isolated ProxyInfo object. I haven't looked at the Firefox code, so I'm not sure if Firefox will use the modifications or ignore it. Personally, I think we should begin working on this within the next month or two, and begin testing the new implementation in the alpha series before we start rebasing Tor Brower onto the next ESR. - Matt

3 3

Planning TBA-a3, the next major Tor Browser for Android milestone
by Georg Koppen 11 Dec '18

11 Dec '18

Hi all, We recently released Tor Browser for Android 8.5a5 which was the second big milestone on our roadmap for mobile[1] and we start planning for the next one, TBA-a3. I started to look over all the open mobile tickets (and filed some that were missing) and tagged all those that we should have fixed for the next big milestone, TBA-a3[2]. Criteria for that were Sponsor8 requirements and impact of bugs for users. Please go through the list and think about whether there are tickets/bugs missing or not needed on it. Additionally, there are "parity" items I started at the end of the roadmap. If there are things I missed in those sections, then let's get them added! TBA-a3 is planned to be the last milestone which should have all the major pieces in place, which we want to have for the first stable release. Please join us in our planning meeting if you are interested. It will be on Thursday, 1900UTC, presumably in #tor-meeting on the OFTC network. (igt0, I hope this works for you as well. Please speak up if not.) Georg [1] https://pad.riseup.net/p/tbb-roadmap-2018-19 [2] https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TBA…

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev December 2018