Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:28:28Zhttps://gitlab.torproject.org/legacy/trac/-/issues/31066Consider protection against requests going through catch-all circuit2020-06-16T01:28:28ZAlex CatarineuConsider protection against requests going through catch-all circuitWhile taking a look at upstreaming #26353 to Firefox I was thinking whether it would make sense to have some mitigations to reduce potential anonymity loss if there are requests unintentionally going through the catch-all circuit. We cur...While taking a look at upstreaming #26353 to Firefox I was thinking whether it would make sense to have some mitigations to reduce potential anonymity loss if there are requests unintentionally going through the catch-all circuit. We currently isolate requests by `originAttributes.firstPartyDomain`. If `originAttributes.firstPartyDomain` is empty, then the request goes to the catch-all circuit (socks username `--unknown--`).
I would suggest changing this and proxying with socks username `--unknown--|||firstPartyDomain(request)` instead, where `firstPartyDomain` is calculated as if the request host was the origin. I think this can only improve user anonymity wrt current behaviour, at the cost of potentially worse network performance (more circuits). But I think there should not be many cases were `firstPartyDomain` is empty, and also not so many `--unknown-- + domain` combinations to make this a performance issue. I think it should be seen just as a mitigation for the potential cases in Tor Browser that might not obey first party isolation.
Not sure if this has already been discussed in the past, but I thought it might be interesting to consider.https://gitlab.torproject.org/legacy/trac/-/issues/30490Add cbindgen project for building Firefox 68 ESR2020-06-16T01:25:41ZGeorg KoppenAdd cbindgen project for building Firefox 68 ESRWe need to provide `cbindgen` for compiling Firefox. Right now it looks like we want to use 0.8.6, but actually whatever makes it into ESR 68.We need to provide `cbindgen` for compiling Firefox. Right now it looks like we want to use 0.8.6, but actually whatever makes it into ESR 68.https://gitlab.torproject.org/legacy/trac/-/issues/30323Adapt macOS toolchain for Firefox 68 ESR2020-06-16T01:25:38ZGeorg KoppenAdapt macOS toolchain for Firefox 68 ESRThis is the (parent) ticket for adapting our toolchain for macOS bundles
built from Firefox 68 ESR.This is the (parent) ticket for adapting our toolchain for macOS bundles
built from Firefox 68 ESR.https://gitlab.torproject.org/legacy/trac/-/issues/28729Think about enabling pointer events again in Tor Browser based on esr682020-06-16T01:11:45ZGeorg KoppenThink about enabling pointer events again in Tor Browser based on esr68In #25794 we disabled pointer events for the time being as parts of Mozilla's defense were not ready yet and/or were largish backports.
We should think about switching to Mozilla's defense and enabling pointer events again where they ar...In #25794 we disabled pointer events for the time being as parts of Mozilla's defense were not ready yet and/or were largish backports.
We should think about switching to Mozilla's defense and enabling pointer events again where they are enabled by a default Firefox.https://gitlab.torproject.org/legacy/trac/-/issues/31396Communication with noscript for security settings not working in nightlies2020-06-16T01:08:12ZAlex CatarineuCommunication with noscript for security settings not working in nightliesIn current nightlies, changing security level does not modify NoScript settings. However, I verified that uninstalling the default NoScript, restarting the browser and installing NoScript from mozilla's addons page fixes this.In current nightlies, changing security level does not modify NoScript settings. However, I verified that uninstalling the default NoScript, restarting the browser and installing NoScript from mozilla's addons page fixes this.https://gitlab.torproject.org/legacy/trac/-/issues/29430Use uTLS for meek TLS camouflage in Tor Browser2020-06-16T01:07:53ZDavid Fifielddcf@torproject.orgUse uTLS for meek TLS camouflage in Tor BrowserNow that meek and meek_lite have or will soon have support for TLS camouflage using uTLS (#29077), we have the option of using that instead of the meek-http-helper headless Firefox extension.
The torrc line:
```
ClientTransportPlugin me...Now that meek and meek_lite have or will soon have support for TLS camouflage using uTLS (#29077), we have the option of using that instead of the meek-http-helper headless Firefox extension.
The torrc line:
```
ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- ./TorBrowser/Tor/PluggableTransports/meek-client
```
will lose the meek-client-torbrowser to become just
```
ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-client
```
In bridge_prefs.js, the bridge line will get an additional `utls` parameter:
```
meek 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com utls=HelloIOS_Auto
```
There's the option of continuing to use the same meek repo as we do now; or of removing that code and using obfs4proxy instead, since they both have uTLS support. Using obfs4proxy will have the advantage of smaller packaging, because there will be one binary instead of two.
There's one more complication, which is tor-launcher and Moat. tor-launcher has its own meek configuration separate from Tor Browser's. It gets the path to the meek-client executable [from the control port](https://gitweb.torproject.org/tor-launcher.git/tree/src/chrome/content/network-settings.js?h=0.2.18#n539) (ultimately from torrc-defaults), but it has [its own version](https://gitweb.torproject.org/tor-launcher.git/tree/src/defaults/preferences/prefs.js?h=0.2.18#n48) of the `url=` and `front=` parameters, and it [passes those to the executable](https://gitweb.torproject.org/tor-launcher.git/tree/src/modules/tl-bridgedb.jsm?h=0.2.18#n211) to the executable as `-url` and `-front` command line arguments, not as SOCKS args. meek-client with uTLS has a `-utls` command line arg, so that's easy to adapt; but since obfs4proxy doesn't understand those command line args, either obfs4proxy would have to add them, or tor-launcher would have to start passing them as SOCKS args.https://gitlab.torproject.org/legacy/trac/-/issues/30682Adapt Intermediate Preloading for Tor Browser2020-06-16T01:07:31ZcypherpunksAdapt Intermediate Preloading for Tor BrowserCan we turn https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading into something useful for ESR68?Can we turn https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading into something useful for ESR68?https://gitlab.torproject.org/legacy/trac/-/issues/30845Make sure default Firefox themes are enabled on ESR682020-06-16T01:06:52ZAlex CatarineuMake sure default Firefox themes are enabled on ESR68With current `000-tor-browser.js` prefs default theme extensions are not installed. `AddonManager.maybeInstallBuiltinAddon` is used to install these, which requires enabledScopes to have flag 4 (application scope). So changing `extension...With current `000-tor-browser.js` prefs default theme extensions are not installed. `AddonManager.maybeInstallBuiltinAddon` is used to install these, which requires enabledScopes to have flag 4 (application scope). So changing `extensions.enabledScopes` from 1 to 5 fixes this.
My understanding is that this should only allow installing extensions from application directory, which we control. Is there any reason not to do this change?
Also, some related prefs seem obsolete:
```
extensions.bootstrappedAddons
extensions.enabledAddons
extensions.enabledItems
```
We could also use this to clean them up.https://gitlab.torproject.org/legacy/trac/-/issues/31467Switch to clang for cctools project2020-06-16T01:06:40ZGeorg KoppenSwitch to clang for cctools projectWe switched away from the `llvm` project for being used in `firefox` and `macosx-toolchain` in favor of `clang`. We should do the same for `cctools` and then get rid of the `llvm` project altogether.We switched away from the `llvm` project for being used in `firefox` and `macosx-toolchain` in favor of `clang`. We should do the same for `cctools` and then get rid of the `llvm` project altogether.https://gitlab.torproject.org/legacy/trac/-/issues/31447Don't install python just for mach2020-06-16T01:06:34ZGeorg KoppenDon't install python just for machWe are currently installing `python` just for `mach`. If we need an extra Python here then we should use the one we build ourselves already (or amend that so that it can be used).We are currently installing `python` just for `mach`. If we need an extra Python here then we should use the one we build ourselves already (or amend that so that it can be used).https://gitlab.torproject.org/legacy/trac/-/issues/31389Update Android Firefox to Build with Clang2020-06-16T01:06:27ZShane IsbellUpdate Android Firefox to Build with Clanghttps://gitlab.torproject.org/legacy/trac/-/issues/31388Update Rust Project for Android2020-06-16T01:06:26ZShane IsbellUpdate Rust Project for AndroidUpdate Rust Project for Android config optionsUpdate Rust Project for Android config optionshttps://gitlab.torproject.org/legacy/trac/-/issues/31322Fix about:tor assertion failure in esr68 linux debug builds2020-06-16T01:06:06ZAlex CatarineuFix about:tor assertion failure in esr68 linux debug buildsI found this assertion failure when testing #30429 in linux, debug build. It happens when loading `about:tor`:
`Assertion failure: foundDefaultSrc (about: page must contain a CSP including default-src), at /home/user/tor/tor-browser/dom...I found this assertion failure when testing #30429 in linux, debug build. It happens when loading `about:tor`:
`Assertion failure: foundDefaultSrc (about: page must contain a CSP including default-src), at /home/user/tor/tor-browser/dom/base/Document.cpp:5179`
We should investigate this, but not sure if it's `tbb-9.0-must-nightly`.https://gitlab.torproject.org/legacy/trac/-/issues/31298Backport patch for #240562020-06-16T01:06:02ZAlex CatarineuBackport patch for #24056https://bugzilla.mozilla.org/show_bug.cgi?id=1561322https://bugzilla.mozilla.org/show_bug.cgi?id=1561322https://gitlab.torproject.org/legacy/trac/-/issues/31209View PDF in Tor browser is fuzzy2020-06-16T01:05:52ZTracView PDF in Tor browser is fuzzyThis is open in Edge(or other normal PDF viewer, include PDF.js):
![https://i.loli.net/2019/07/21/5d342843868e089809.png](https://i.loli.net/2019/07/21/5d342843868e089809.png)
This is open in Tor browser(with PDF.js):
![https://i.loli.ne...This is open in Edge(or other normal PDF viewer, include PDF.js):
![https://i.loli.net/2019/07/21/5d342843868e089809.png](https://i.loli.net/2019/07/21/5d342843868e089809.png)
This is open in Tor browser(with PDF.js):
![https://i.loli.net/2019/07/21/5d342843dd2f844657.png](https://i.loli.net/2019/07/21/5d342843dd2f844657.png)
It's same with all PDF.
**Trac**:
**Username**: nullhttps://gitlab.torproject.org/legacy/trac/-/issues/31173Update android-toolchain project to match firefox2020-06-16T01:05:48ZShane IsbellUpdate android-toolchain project to match firefoxThis includes ndk 17 and android build tools 27.This includes ndk 17 and android build tools 27.https://gitlab.torproject.org/legacy/trac/-/issues/31162Web Compatibility should work and override RFP, but investigation is needed2020-06-16T01:05:46ZcypherpunksWeb Compatibility should work and override RFP, but investigation is neededChrome-ish future...
https://www.ghacks.net/2019/07/15/firefox-68-aboutcompat-launches/Chrome-ish future...
https://www.ghacks.net/2019/07/15/firefox-68-aboutcompat-launches/https://gitlab.torproject.org/legacy/trac/-/issues/31142One tab crashed and transformed the other tab to about:newtab with no history!2020-06-16T01:05:42ZcypherpunksOne tab crashed and transformed the other tab to about:newtab with no history!What a mess!What a mess!https://gitlab.torproject.org/legacy/trac/-/issues/31134Reenable Graphite for font rendering2020-06-16T01:05:39ZGeorg KoppenReenable Graphite for font renderingWe disabled using Graphite for font rendering (after trying to reenable it) back in #21726 for security reasons. Things have settled down it seems. Thus, we should reenable it and put it back on the security slider this time.We disabled using Graphite for font rendering (after trying to reenable it) back in #21726 for security reasons. Things have settled down it seems. Thus, we should reenable it and put it back on the security slider this time.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/31120Enable AssertSystemPrincipalMustNotLoadRemoteDocuments2020-06-16T01:05:33ZTom Rittertom@ritter.vgEnable AssertSystemPrincipalMustNotLoadRemoteDocumentsAssertSystemPrincipalMustNotLoadRemoteDocuments is a defense in depth mitigation Tor should ensure is used by default.
This will involve removing some ifdefs and possibly backporting the updates to the function from -central to -esr68AssertSystemPrincipalMustNotLoadRemoteDocuments is a defense in depth mitigation Tor should ensure is used by default.
This will involve removing some ifdefs and possibly backporting the updates to the function from -central to -esr68