November 2017 - tbb-dev - lists.torproject.org

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

Re: [tbb-dev] [tor-dev] RFC: porting torbrowser (was: Re: GNU Guix and Tor Browser Packaging)
by ng0 09 Mar '18

09 Mar '18

Hi, It seems as if tbb-dev(a)lists.torproject.org is the list which would be more appropriate. If the 7 days without a reaction are simply due to the holidays in some countries, it's my mistake. If you need internal discussion about this to respond appropriately, let me know that you are reviewing this message at all. I have no expectation for "neoliberal optimized" reply times. Thanks. ng0 transcribed 7.9K bytes: > Hi folks, > > as your trademarks team / person suggested to me I get in touch with the > dev team of torproject. While I'm more involved in GNUnet, I work at the > intersection of projects. Currently this means I'm involved in system > integration. At Guix we are interested in working closer with projects > like tor, TAILS, Whonix and the like. Porting torbrowser is not only in > the interest of the Guix community but also in the interest of Wonix who > recently expressed interest in selectively using Guix for their work. > For me as maintainer of the system (in development) pragmaOS it also > means that we can decide between icecat OR torless torbrowser for > proxied GNUnet connections. > > I'm interested in your response to the actions listed below and wether > you think this will still qualify as torbrowser or what other option you > propose for us at Guix to use. "Option" here means that I am not sure > what other graphical theme you have for versions of the browser which do > not use the trademark when they can (logically) also not use the firefox > trademarks. > I would reflect in the description of the package that it is not > torbrowser but a reconstruction of the way torbrowser is build, tracking > upstream as closely as possible while removing (list of features which > were removed goes here). > This can be compared to what the inoffical Gentoo maintainer does in the > .ebuild file here: > https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/ > > My request here is just in the position as a contributor to Guix, not > for pragmatique (the project which works on pragmaOS etc), Whonix, > GNUnet or any other project I mentioned before. > > Thanks in advance. Now the content I've been talking about: > > It looks like the changes I need to make to torbrowser are not so > grave at all. Someone pointed me to the gnu-linux-libre(a)nongnu.org list > to reach out to other FSDG systems. > The thread can be reviewed here: > https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-03/msg00002.html > > Basically: > > I will need to discourage Mozilla leftovers: > - the mozilla addon service will be overwritten, in other words: > Where you would find https://addons.mozilla.org/ at "Preferences > AddOns" > it will be replaced by the thing Icecat points to. Longterm plan is > to offer firefox extensions native through "guix package -i > youraddonnamehere". > > Privacy / Tracking reasons: > - Firefox "Sync" will be disabled. > - Google will be removed from the search plugins if I understood the > procedure correctly (at least it is not in Icecat) > > A question directly for torbrowser team: > - about:license does not list licenses the torbrowser project uses, only > firefox. Why? > > DRM > - Luke from parabola mentioned that drm has been enabled in recent > versions of torbrowser. This needs to be removed aswell. > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/vendor.js#n23 > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/mozconfig#n39 > https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/fire… > > ng0 transcribed 3.4K bytes: > > bancfc(a)openmailbox.org transcribed 1.9K bytes: > > > There is a serious Tor Browser packaging effort [3][4] being done by ng0 > > > (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports > > > > Eh, now that the cat is out of the bag (cat's don't belong into bags > > anyway), I think I have to do this now and not on my own conditions. > > > > Hi! > > > > As I told bancfc somewhere else, I've had a short contact with the > > trademarks team of torproject. I will get back to you when someone was > > able to identify issues in torbrowser which might lead to modifications > > of torbrowser (for more details I just hope trademarks(a)tp.o can > > communicate it to you) because all packaged software which is included > > in upstream of Guix (master) must follow the GNU Free System > > Distribution Guidelines. > > I hope that I have to make as little modifications as possible as I > > I am aware that the fingerprint of the browser could change depending on > > the kind of changes. > > > > I hope to get back to this task in about 3 weeks, right now I'm busy > > with getting more documentation done for another project. > > > > > transactional upgrades and roll-backs, unprivileged package management, > > > per-user profiles and most importantly reproducible builds. I have checked > > > with Guix's upstream and they are working on making a binary mirror > > > available over a Tor Hidden Service. [2] Also planned is resilience [2] to > > > the attack outlined in the TUF threat model. [1] > > > > > > Back to the topic of Tor Browser packaging. While there are good reasons for > > > Debian's pakaging policies they make packaging of fast evolving software > > > (and especially with TBB's reliance on a opaque binary VM for builds) > > > impractial. Both we and Micah have been doing a good effort to automate > > > downloading and validating TBB but I still believe its a maintenance burden > > > and Guix may be a way out of that for Linux distros in general. > > > > > > What are your thoughts on this? > > > > > > > > > > > > > > > > > > *** > > > > > > [0] https://www.gnu.org/software/guix/ > > > [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md > > > [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html > > > [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html > > > [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html > > > _______________________________________________ > > > tor-dev mailing list > > > tor-dev(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- > PGP and more: https://people.pragmatique.xyz/ng0/ > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- PGP and more: https://people.pragmatique.xyz/ng0/

4 8

Tor Browser proxy settings
by Tom Ritter 07 Dec '17

07 Dec '17

Hey folks, nmago is continuing work on the crash reporter, and ran into some proxy problems. He's trying to get the proxy settings inside the crash reporter tool but the crash reporter tool can't read Firefox's proxy settings! Upstream this is talked about in https://bugzilla.mozilla.org/show_bug.cgi?id=1388897 https://bugzilla.mozilla.org/show_bug.cgi?id=1333125 and he asked here: https://groups.google.com/forum/#!topic/mozilla.dev.platform/opiD1Rz-e68 I'm wondering if in Tor Browser we can run around Firefox' lack of support here and: A) If we hardcode the proxy settings (fixed port) than nmago can just hardcode it in the crash reporter OR B) If we choose a random port, if we can make that information available to the crash reporter somehow. If we do (B), is the port chosen written out into a torrc file he could read? Or is it determined on startup and only held in memory? This gets tricky because we don't really want to write anything to disk and other IPC mechanisms (Environment Variables) are concerning... (but maybe acceptable from our threat model?) -tom

3 3

Changes to plist on Mac may affect disk leakage
by Tom Ritter 04 Dec '17

04 Dec '17

spohl (cc-ed) let me know that he's going to be reverting https://bugzilla.mozilla.org/show_bug.cgi?id=967970 and landing https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 to address issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1418903 In particular, reverting the first issue prevent window title disk leaks, but the new patch should still address that need. -tom

3 4

Exposing TB as Tor Browser
by Tom Ritter 27 Nov '17

27 Nov '17

Background: Firefox added the Canvas Permission Prompt, people turned it on. They discovered that blog.mozilla.com was triggering it, investigated. Tracked it down to Wordpress, by default, using canvas to figure out if the user has emoji support. Fairly innocuous use, not for tracking. Wordpress would like to detect Tor Browser so it doesn't perform the check and therefore doesn't pop the prompt. This would significantly reduce the number of prompts Tor Browser users are seeing. The (old) ticket is here: https://trac.torproject.org/projects/tor/ticket/18195 Other links: Original WP ticket: https://core.trac.wordpress.org/ticket/32138 Mozilla Ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1413182 New WP Ticket: https://core.trac.wordpress.org/ticket/42428 Is this something TB would take as a patch? -tom PS: Unless FF with privacy.resistFingerprinting identified itself as Tor Browser, this wouldn't help FF, just TB. But maybe FF _should_ identify itself as TB if TB starts identifying itself as TB?

4 6

[tag] sandboxed-tor-browser-0.0.16.
by Yawning Angel 24 Nov '17

24 Nov '17

Hello, I just tagged sandboxed-tor-browser-0.0.16. Changes in version 0.0.16 - 2017-11-24: * Bug 24171: Create the `Caches` directory properly. This is a bugfix release. Normally I'd sit on this some more, because one minor change doesn't usually justify a release, but with the current pace of development, I might as well tag a release and get it over with. Regards, -- Yawning Angel

1 0

Bug: plugin-container exhausts memory leading to thrash and/or crash
by astian 24 Nov '17

24 Nov '17

(Re-sending after subscribing to the list.) STR --- 1. Run one of the platforms affected by the recent "tormoil" vulnerability (I tested this on a GNU/Linux distro). 2. Under Tor Browser 7.0.10's installation directory, create `Browser/TorBrowser/Data/Browser/profile.default/chrome/userContent.css` with the following content (you can use whatever you want here, just adjust the next steps accordingly): body { background-color: blue !important; color: white !important; } 3. Start Tor Browser. 4. Confirm that the content background looks blue. 5. Right click the blue background on an empty spot (body element) and choose "Inspect Element". 6. Wait until the Inspector window shows up. Observe memory consumption of process "plugin-container" continually rise. Analysis -------- I think this regression is caused by the workaround [0] for the recent critical vulnerability [1], but it has exposed what looks to me (not being privy to the details of "tormoil") like another bug, this one in javascript code. 0: https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.0e… 1: https://trac.torproject.org/projects/tor/ticket/24052 `newChannelForURL` in DevToolsUtils.js (packed inside `Browser/browser/omni.ja`) will recursively call itself when `NetUtil.newChannel` raises an exception, prepending "file://" to the input URL: /** * Opens a channel for given URL. Tries a bit harder than NetUtil.newChannel. * * @param {String} url - The URL to open a channel for. * @param {Object} options - The options object passed to @method fetch. * @return {nsIChannel} - The newly created channel. Throws on failure. */ function newChannelForURL(url, { policy, window, principal }) { var securityFlags = Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL; let uri; try { uri = Services.io.newURI(url, null, null); } catch (e) { // In the xpcshell tests, the script url is the absolute path of the test // file, which will make a malformed URI error be thrown. Add the file // scheme to see if it helps. uri = Services.io.newURI("file://" + url, null, null); } [...] try { return NetUtil.newChannel(channelOptions); } catch (e) { // In xpcshell tests on Windows, nsExternalProtocolHandler::NewChannel() // can throw NS_ERROR_UNKNOWN_PROTOCOL if the external protocol isn't // supported by Windows, so we also need to handle the exception here if // parsing the URL above doesn't throw. return newChannelForURL("file://" + url, { policy, window, principal }); } } With the mentioned patch, the call to `NetUtil.newChannel` raises an exception. This results in infinite recursion coupled with rapid (though linear) memory consumption. Thus, `plugin-container` will, in just a few seconds, exhaust all available memory. Partial fix ----------- AFAICT, the current patch for "tormoil" is just a hurried stop-gap workaround and as such it is acceptable, and somewhat expected, for it to cause other, less severe, kinds of breakage. However, ISTM that the code in `newChannelForURL` is buggy regardless: the recursion has no (evident) termination condition. The comment before the recursive call says that it is needed due to some tests for which `newChannel` can raise `NS_ERROR_UNKNOWN_PROTOCOL`. So maybe it should only catch the exception (and make the recursive call) if the error is that one and `url` does not already start with "file://". The attached patch does this. It does not fix the regression (the Developer Toolbox still fails to show the appropriate styles and stylesheets), but at least fixes the DoS caused by the runaway memory allocation. Cheers. PS: How about fixing your bug tracker? It's impossible to register an account. Bloody google captchas? Free labour for google from the tor community courtesy of tor inc., isn't that lovely (never mind the fact that they require javascript, and even then never actually work). Ridiculous.

2 1

FYI: Removing --disable-crashreporter
by Tom Ritter 23 Nov '17

23 Nov '17

https://bugzilla.mozilla.org/show_bug.cgi?id=1402519 Replacing it with a dummy crash reporter that just doesn't do anything.

1 0

[roadmap process] follow up with other teams
by isabela 20 Nov '17

20 Nov '17

Hi Tor Browser team! This Friday Nov 17 is the when the 'chatting' time ends and we start with execution. This is just symbolic, of course you will not stop talking with other people! But hopefully by this Friday you and the teams who wrote questions related to the Tor Browser team roadmap, has either addressed them and all is good, or made a plan on how to stay in touch as you work on stuff. I am sending a similar note to all teams. I also would like to call your attention to Services and UX Team roadmaps that were added to the pad: https://storm.torproject.org/shared/m-IG6BIam2M9tF6rLDKFpBtIaUoTABiXLN17N97… If you have questions for them, there is an section for them at the questions pad: https://storm.torproject.org/shared/6_vKbNygWaF8WcG6xz3lTW6RWbJzlBdm8ZezRYW… Finally, below are the questions other teams wrote to Tor Browser team, please take a look at them and follow up with whatever is necessary: Questions/Comments for Tor Browser (mobile and desktop) roadmap: https://storm.torproject.org/shared/roevbMxlBi5rxSAh57iRjy8w1MB2HZArEmM2Jek… [Network] These descriptions are pretty terse; we may have missed something. [Network] Can you put anything on your roadmap about Rust build adoption? [GeKo: It's not explicitly there yet as this is done during the ESR 59 transition. And the important part where we usually adapt the toolchains to the new ESR requirements starts in March when the roadmap ends. That said we could think about starting earlier this time for the tor case.] [NM: I'd recommend that you start getting Rust build experience ahead of schedule to identify issues.] [Network] Can you say more about "QA infrastructure" and "release process planning"? How do they affect us? [Network] Should our improvements to bootstrap UX be on your radar? [GeKo: They should. And I looked over the items on the network team map] [Network] Should our improvements to mobile app development API be on your radar? [Network] Please remember to start testing our outputs sooner than you need them: it's easier to fix problems the earlier we find out about them! [Community] We should have regular checkins about support (actually as I'm typing this I see that you flagged it under our roadmap too). [OONI] When will the new launcher UI be shipped?

2 1

Fwd: [community] Computer forensics & Tor (Was: (no subject))
by Tommy Collison 17 Nov '17

17 Nov '17

Good call, thanks teor. TC On 11/17/17 2:05 PM, teor wrote: > > Hi Tommy, > > This might be best directed to the Tor Browser team? > (Or both network and Tor Browser teams.) > > I hope the OS used is Windows, as it's our most popular. > Or Linux, as it's the one that our ultra-secure distributions are based upon > (TAILS, Qubes, Whonix…) > > T > >> On 18 Nov 2017, at 05:59, Tommy Collison <tommyc(a)torproject.org> wrote: >> -------- Forwarded Message -------- >> Subject: [community] (no subject) >> Date: Tue, 14 Nov 2017 20:34:27 +0000 >> From: Scott Ainslie <scott(a)scottainslie.me.uk> >> To: tor-community-team(a)lists.torproject.org >> >> Hello, >> >> I'm intending to publish a term paper. I'm in the midst of outlining >> its remit, but I hope that the outcome benefits the organization and >> users from the standpoint of computer forensic science. >> >> I specialize in digital forensic science, and hold a Certificate of >> Higher Education in Digital Forensics, and a CERT Digital Forensics >> Professional Certificate from Carnegie Mellon University's Software >> Engineering Institute. >> >> Its been half a decade since the organization published a term paper >> assessing the Web browser from the standpoint of computer forensic >> science, and I feel that undertaking it again might be beneficial. I >> intend to refer to it as a basis for the term paper I'm authoring, as >> there are aspects of it I feel I can embellish. >> >> I feel it might be best if I focus upon a single platform because I'll >> be able to conduct more in-depth research. I'm also able to access a >> lot of resources that I hope might enrich the term paper. >> >> I thought it might be useful and beneficial to coordinate the >> independent research I'm undertaking and I'd be grateful for >> cooperation and topics for discussion. >> _______________________________________________ >> tor-community-team mailing list >> tor-community-team(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-community-team >> <0xA78300BD.asc> >> _______________________________________________ >> network-team mailing list >> network-team(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/network-team

1 0