- tbb-dev - lists.torproject.org

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) … [View More]

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 !… [View More]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. [View Less]

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 … [View More]

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: >> -------- … [View More]

1 0

The next meeting is on Tue, November 21 at 1900 UTC
by Georg Koppen 16 Nov '17

16 Nov '17

Hi all! As a one-time outlier we moved the next Tor Browser meeting to Tuesday next week (November 21 1900 UTC). As usual we'll meet in #tor-meeting. See you there, Georg

1 0

Resolving file url handling issues
by Yuki S 16 Nov '17

16 Nov '17

Hi, I'll be brief What is the stance on fixing the issues (pre/post). How optimistic is it that the bug can be fixed by Mozilla in a reasonable amount of time? Is it really a priority (as Mozilla pushes Quantum) when the issue primarily impacts groups like the TPO community who need a proxy shared on a multi-process design (rhetorical maybe), and doesn't impact the (current) target audience. Mozilla already matches donations so I wonder if it would be fair unless this is a bug not originally … [View More]

2 1

Fwd: Intent to require Python 3 to build Firefox 59 and later
by Tom Ritter 13 Nov '17

13 Nov '17

FYI ---------- Forwarded message ---------- From: Gregory Szorc <gps(a)mozilla.com> Date: 10 November 2017 at 17:27 Subject: Intent to require Python 3 to build Firefox 59 and later To: dev-builds <dev-builds(a)lists.mozilla.org>, dev-platform <dev-platform(a)lists.mozilla.org> For reasons outlined at https://bugzilla.mozilla.org/show_bug.cgi?id=1388447#c7, we would like to make Python 3 a requirement to build Firefox sometime in the Firefox 59 development cycle. (Firefox … [View More]

3 2