- tbb-dev - lists.torproject.org

TBB vs mandatory extension signing
by anonym 18 Apr '17

18 Apr '17

Hi, In Tails we've been wondering what to do about Firefox's mandatory extension signing [1] in FF52ESR since the opt-out preference that we have been using for FF45ESR will be removed from released versions. Today I found the Tor Browser's solution for tor-browser-52.0.2esr-7.0-2 in commit 584c17c1b3e07239b8dd195e8b91eefb2ff9b2f4; here's an extract: function isCorrectlySigned(aAddon) { // Add-ons without an "isCorrectlySigned" property are correctly signed as // they aren't the correct type for signing. + if (aAddon.id == "torbutton(a)torproject.org" || + aAddon.id == "tor-launcher(a)torproject.org" || + aAddon.id == "https-everywhere-eff(a)eff.org") { + return true; + } return aAddon.isCorrectlySigned !== false; } So it's a list of exceptions. In Tails we install two additional extensions we'd like exceptions for: * a localization-related extension that we generate dynamically *during build*, so signing will be impossible. * Ublock Origin, which we install from Debian, and the signature is missing. Can this list of exceptions be moved to an external file that we in Tails can modify instead? I think I have exhausted all options we have on our side. [2] -- I'd also like to ask if you have analysed the security implications of introducing this exception list since I couldn't find any such discussion on the relevant ticket [3]. So, have you? Personally I reacted on that it is a simple match vs the extension's id, e.g. something we should consider attacker-controlled. I haven't looked at the code closely, but I'd expect attackers can deliver their malicious code in extensions that only need to have that same id as some extension with an exception to completely bypass the code signing check. Think, for instance, about an "upgraded" Torbutton. Is my above hunch true? If so I think this approach is a bit dangerous: without the "mandatory" part, this code signing adds a false sense of security. IMHO this approach then either has to be improved (e.g. by also matching on a cryptographic hash of the XPI) or dropped and replaced with a different solution. I think it can be argued that just flipping the build switch that disables the extension code signing checks is preferable. Cheers! [1] https://labs.riseup.net/code/issues/11419 [2] I tried something really ugly: I adjusted our build script to unpack the two affected omni.ja files and patch in our exceptions, but there are binary versions (e.g. XPIProvider.jsm) generated from the patched files, so this doesn't work (or is there an easy way to re-generate the .jsm files?). [3] https://trac.torproject.org/projects/tor/ticket/14970

3 8

TBB gpg signing key rotation plans?
by Patrick Schleizer 18 Apr '17

18 Apr '17

Hi, do you have a schedule for changing to newer TBB gpg signing keys? I am asking, because torbrowser downloaders developers such as of torbrowser-launcher, tb-updater and sandboxed-tor-browser would ideally know about in advance. Cheers, Patrick

2 1

Safe Browsing V4 will replace V2 in Firefox ESR 59
by Ethan Tseng 11 Apr '17

11 Apr '17

Hi all, Mozilla is implementing the new spec version V4 of Safe Browsing. (Currently, Firefox uses SB V2.) We aim at rolling out SB V4 in Firefox ESR 59, which will be released early next year. And Google will shutdown SB V2 service at that time. I presume that this won't affect the Tor Browser since Safe Browsing is disabled by default in TBB according to these prefs: - browser.safebrowsing.enabled = false - browser.safebrowsing.forbiddenURIs.enabled = false - browser.safebrowsing.malware.enabled = false However, I still would like to give this heads up. -- Ethan Tseng Engineering Manager, Mozilla

1 0

First nightly builds based on ESR 52 are available!
by Georg Koppen 11 Apr '17

11 Apr '17

Hi all! We have first nightly builds based on Firefox 52.0.2esr available: https://people.torproject.org/~gk/testbuilds/tbb-nightly/ The location is a bit unusual but we hit an issue in our nightly build Gitian setup which made some tweaking to our usual build and upload process necessary. Nevertheless, please give this nightly a test if you can as we don't have much time left before the first alpha based on ESR 52 is due. Two issues with this nightly are already filed: 1) Modal windows are for some reason maximized which is pretty annyoing (#21875) 2) e10s is not activated on Linux (+ macOS I guess) (#21876) General issues we have on our radar for our ESR52 switch can be found on Trac: https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… If you find more problems, especially stability issues, we'd love to hear about those. Happy testing, Georg

2 2

Next Tor Browser meeting on Monday, April 24 1800 UTC
by Georg Koppen 11 Apr '17

11 Apr '17

Hi, Due to a holiday next Monday we will skip the Tor Browser meeting on that day. The next one will be on Monday, April 24, time and place as usual: 1800 UTC in #tor-dev on the OFTC network. See you there, Georg

1 0

How to use Tor Browser for security not anonymity? How to use TBB using clearnet?
by Patrick Schleizer 10 Apr '17

10 Apr '17

TLDR: 1) How can one easily hack TBB to use clearnet? [1] (idea [2]) 2) How can one enable cookies to persist in TBB? 3) How can one re-enable the Firefox password manager in TBB so one can store passwords? To archive that I've disabled private browser and tinkered with lots of torbutton Firefox config settings to no avail. Could you please kindly advice on how to archive that? Long: Tor Browser is better hardened than regular Firefox and over time, it will be even better hardened, even sandboxed. For clearnet browsing where Tor is either not required or creating a mess (such as online banking), it would be awesome if one could use Tor Browser without going through Tor. I guess it's very safe to assume, the most users won't use TBB exclusive. They also want to use clearnet. But the value of a super hardened secure browser TBB is somewhat reduced when then using a non-hardened browser for clearnet use, which could lead to system compromise. Of course this TBB hacking for clearnet use would for now only be advise able for advancement users to not mess up a Tor Browser actually using Tor vs a Tor Browser actually using clearnet. Would be up to oneself to have some protections in place such as using a dedicated VM or computer for that purposes so that one won't accidentally confuse one browser with another. Cheers, Patrick [1] I hear, at some point in future, TBB will no longer have TCP compiled in, and only use unix domain sockets. That's awesome for TBB use with Tor, but makes TBB use with clearnet hard. Long term a solution to redirect TOR_SOCKS_IPC_PATH to clearnet would be needed. [2] Idea how to hack TBB to use clearnet. We could set these environment variables: export TOR_NO_DISPLAY_NETWORK_SETTINGS=1 export TOR_SKIP_CONTROLPORTTEST=1 export TOR_SKIP_LAUNCH=1 export TOR_SOCKS_IPC_PATH=/path/to/unix-domain-socket-file then use socat to redirect to unix domain socket file to 9150. On 9150, we could have a local ssh server running sudo apt-get install openssh-server and then use ssh to open a local socks port forwarding to our local ssh server, which then would use clearnet. sudo apt-get install openssh-client ssh -D 9150 user(a)127.0.0.1

2 1

trouble building tor-browser-bundle.git
by Arthur D. Edelstein 09 Apr '17

09 Apr '17

Hi all, I'm running into the following build errors when I enter `./mkbundle-linux.sh versions.nightly`: I: Base system installed successfully. cp: cannot stat ��base-jessie-amd64-bootstrap/usr/lib/x86_64-linux-gnu/lxc/lxc-init��: No such file or directory cp: cannot stat ��base-jessie-amd64��: No such file or directory amd64 jessie VM creation failed Any advice on what I might be doing wrong? My build machine is jessie 8.7, in case it's relevant. Thanks, Arthur

2 3

Fwd: Moving the 53 Merge and Release dates to accomodate Easter holiday
by Nicolas Vigier 06 Apr '17

06 Apr '17

FYI: The next release date has been moved by one day. ----- Forwarded message from "Liz Henry (:lizzard)" <ehenry(a)mozilla.com> ----- Date: Thu, 6 Apr 2017 11:31:39 -0700 From: "Liz Henry (:lizzard)" <ehenry(a)mozilla.com> To: release-drivers <release-drivers(a)mozilla.org> Cc: dev-platform <dev-platform(a)lists.mozilla.org>, tw-all(a)mozilla.com, communications <communications(a)mozilla.com>, fx-team <fx-team(a)mozilla.com> Subject: Moving the 53 Merge and Release dates to accomodate Easter holiday Hi release-drivers and others, Because Monday April 17th is part of the Easter holiday in many countries, we decided to move the Firefox 53 merge and release dates by one day. Merge day will now be Tuesday, April 18, and we plan to release Firefox 53 on Wednesday, April 19. The dates are changed in the public release calendars. Best, Liz -- ---- Liz Henry (:lizzard) Firefox Release Manager lhenry(a)mozilla.com _______________________________________________ dev-platform mailing list dev-platform(a)lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ----- End forwarded message -----

1 0

versions.* files in tor-browser-bundle.git
by Arthur D. Edelstein 05 Apr '17

05 Apr '17

Hi everyone, In tor-browser-bundle.git we have four "versions" files: versions versions.alpha versions.beta versions.nightly But, similar to tor-browser.git and torbutton.git, we also have release and alpha branches, e.g.: remotes/origin/maint-5.5 remotes/origin/maint-6.0 remotes/origin/maint-6.5 remotes/origin/master And, most of the hashes and other lines in the various versions* files are the same with only minor differences. So I'm wondering if the versions.* files (with dot) are unnecessary. Maybe we only need a single versions file in each branch? Instead we could introduce any needed flags that specify whether we want to verify inputs, etc. Thanks, Arthur

2 1

Next Tor Browser meeting time: Monday, April 3 1800 UTC in #tor-dev
by Georg Koppen 28 Mar '17

28 Mar '17

Hi all! As some of you might have realized there has been no Tor Browser meeting yesterday due to the meeting in Amsterdam. For the next meeting and the ones following that one we will change the time to 1800 UTC following daylight savings done in the US and Europe. Thus, the next meeting will happen on Monday, April 3 1800 UTC in #tor-dev on the OFTC IRC network. See you there, Georg

1 0