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'…
[View More]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
[View Less]
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
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.…
[View More]enabled = false
However, I still would like to give this heads up.
--
Ethan Tseng
Engineering Manager, Mozilla
[View Less]
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 …
[View More]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
[View Less]
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
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 …
[View More]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
[View Less]
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
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 …
[View More]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 -----
[View Less]
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 …
[View More]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
[View Less]
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