Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:26:33Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34391Remove --enable-signmar from .mozconfig files2020-06-16T01:26:33ZGeorg KoppenRemove --enable-signmar from .mozconfig filesSince https://bugzilla.mozilla.org/show_bug.cgi?id=1562952 landed there is no `--enable-signmar` anymore. We should remove it from our Linux .mozconfig files.Since https://bugzilla.mozilla.org/show_bug.cgi?id=1562952 landed there is no `--enable-signmar` anymore. We should remove it from our Linux .mozconfig files.https://gitlab.torproject.org/legacy/trac/-/issues/34390Update build script to remove copying libnssdbm3.so around2020-06-16T01:26:33ZGeorg KoppenUpdate build script to remove copying libnssdbm3.so aroundSince https://bugzilla.mozilla.org/show_bug.cgi?id=1594933 landed there is no `libnssdbm3.so` file built anymore by default.Since https://bugzilla.mozilla.org/show_bug.cgi?id=1594933 landed there is no `libnssdbm3.so` file built anymore by default.https://gitlab.torproject.org/legacy/trac/-/issues/34389Multi-Account Container extension "corrupt" upon installation2020-06-16T01:13:18ZTracMulti-Account Container extension "corrupt" upon installationHi. I'm running TB 9.5 on Ubuntu 20.04. To further improve my privacy, I'd like to install Multi-Account Containers extension to have cookie (session) isolation between tabs. I've tried installing versions that I verified work in vanilla...Hi. I'm running TB 9.5 on Ubuntu 20.04. To further improve my privacy, I'd like to install Multi-Account Containers extension to have cookie (session) isolation between tabs. I've tried installing versions that I verified work in vanilla Firefox. All attempts fail with same error "The add-on downloaded from this site could not be installed because it appears to be corrupt." Screenshot here: https://i.imgur.com/zlCxx2I.png
**Trac**:
**Username**: TechyGruehttps://gitlab.torproject.org/legacy/trac/-/issues/34388Update lucetc and wasi-sdk projects to latest ESR 78 code2020-06-16T01:26:32ZGeorg KoppenUpdate lucetc and wasi-sdk projects to latest ESR 78 codeIn order to properly enable WASM sandboxing we should update our `lucetc` and `wasi-sdk` projects to what Mozilla ships in ESR 78.In order to properly enable WASM sandboxing we should update our `lucetc` and `wasi-sdk` projects to what Mozilla ships in ESR 78.https://gitlab.torproject.org/legacy/trac/-/issues/34387Fix Namecoin patches for ESR 782020-06-16T01:26:32ZGeorg KoppenFix Namecoin patches for ESR 78We need to adapt our Namecoin patches to ESR 78We need to adapt our Namecoin patches to ESR 78https://gitlab.torproject.org/legacy/trac/-/issues/34386Fixup clang compilation for Linux2020-06-16T01:26:32ZGeorg KoppenFixup clang compilation for LinuxWe need to fix up our clang compilation for Linux. Right now, with 9.0.1 we get:
```
/var/tmp/build/llvm/projects/compiler-rt/lib/crt/crtbegin.c:86:16: error: section type conflict with '__EH_FRAME_LIST__'
86 | used)) s...We need to fix up our clang compilation for Linux. Right now, with 9.0.1 we get:
```
/var/tmp/build/llvm/projects/compiler-rt/lib/crt/crtbegin.c:86:16: error: section type conflict with '__EH_FRAME_LIST__'
86 | used)) static void (*__fini)(void) = __do_fini;
| ^~~~
/var/tmp/build/llvm/projects/compiler-rt/lib/crt/crtbegin.c:13:28: note: '__EH_FRAME_LIST__' was declared here
13 | __extension__ static void *__EH_FRAME_LIST__[]
| ^~~~~~~~~~~~~~~~~
make[2]: *** [lib/clang/9.0.1/lib/linux/clang_rt.crtbegin-i386.o] Error 1
```https://gitlab.torproject.org/legacy/trac/-/issues/34385Be consistent with onion service terms2020-06-16T01:13:18ZMatthew FinkelBe consistent with onion service termsRecently Gus, Al, and I had a conversation about whether we should use "onionsite" or "onion site". We decided "onion site" is better for new users, and that is the better option. I noticed we use "onionsite" in Tor Browser. We should co...Recently Gus, Al, and I had a conversation about whether we should use "onionsite" or "onion site". We decided "onion site" is better for new users, and that is the better option. I noticed we use "onionsite" in Tor Browser. We should correct those instances. Are there other terms we should correct?
torbutton:
```
$ git grep -n onionsite chrome/locale/en-US/
chrome/locale/en-US/torbutton.properties:75:onionServices.descNotFound=The most likely cause is that the onionsite is offline. Contact the onionsite administrator.
chrome/locale/en-US/torbutton.properties:80:onionServices.descInvalid=The onionsite is unreachable due an internal error.
chrome/locale/en-US/torbutton.properties:85:onionServices.introFailed=The most likely cause is that the onionsite is offline. Contact the onionsite administrator.
chrome/locale/en-US/torbutton.properties:90:onionServices.rendezvousFailed=The onionsite is busy or the Tor network is overloaded. Try again later.
chrome/locale/en-US/torbutton.properties:95:onionServices.clientAuthMissing=Access to the onionsite requires a key but none was provided.
chrome/locale/en-US/torbutton.properties:100:onionServices.clientAuthIncorrect=The provided key is incorrect or has been revoked. Contact the onionsite administrator.
chrome/locale/en-US/torbutton.properties:105:onionServices.badAddress=The provided onionsite address is invalid. Please check that you entered it correctly.
chrome/locale/en-US/torbutton.properties:110:onionServices.introTimedOut=Failed to connect to the onionsite, possibly due to a poor network connection.
chrome/locale/en-US/torbutton.properties:124:onionServices.authPreferences.dialogIntro=Keys for the following onionsites are stored on your computer
```
tor browser:
```
$ git grep -n onionsite browser/modules/TorStrings.jsm
browser/modules/TorStrings.jsm:397: dialogIntro: getString("authPreferences.dialogIntro", "Keys for the following onionsites are stored on your computer"),
browser/modules/TorStrings.jsm:442: "Prioritize onionsites when they are available."
```
Any other places?https://gitlab.torproject.org/legacy/trac/-/issues/34384AppVeyor builds are failing2020-06-13T15:53:45ZAlexander Færøyahf@torproject.orgAppVeyor builds are failingOur AppVeyor builds are failing. It looks like the issue is related to us not updating Pacman before we install our dependencies.Our AppVeyor builds are failing. It looks like the issue is related to us not updating Pacman before we install our dependencies.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34383Accept request if GetHost() in mixed content blocking check fails2020-06-16T01:13:17ZGeorg KoppenAccept request if GetHost() in mixed content blocking check failsWhile reviewing acat's rebase work in #33533 I noticed the following block in our patch for #23247:
```
if (!parentIsHttps) {
+ nsAutoCString parentHost;
+ rv = innerRequestingLocation->GetHost(parentHost);
+ if (NS_FAILED(rv...While reviewing acat's rebase work in #33533 I noticed the following block in our patch for #23247:
```
if (!parentIsHttps) {
+ nsAutoCString parentHost;
+ rv = innerRequestingLocation->GetHost(parentHost);
+ if (NS_FAILED(rv)) {
+ NS_ERROR("requestingLocation->GetHost failed");
+ *aDecision = REJECT_REQUEST;
+ return NS_OK;
+ }
+
+ bool parentIsOnion =
+ StringEndsWith(parentHost, NS_LITERAL_CSTRING(".onion"));
+ if (!parentIsOnion) {
+ *aDecision = ACCEPT;
+ return NS_OK;
+ }
+ }
```
The corresponding part in Mozilla's code looks like [this](https://searchfox.org/mozilla-esr68/source/dom/security/nsMixedContentBlocker.cpp#748):
```
if (!parentIsHttps) {
*aDecision = ACCEPT;
return NS_OK;
}
```
Mozilla does not even check the host but is accepting requests at this point outright while we reject them if `GetHost()` fails.
I wonder whether we should follow them here because I am a little worried that we might introduce a subtle bug by diverging from them.
I guess the question is whether it can be the case that we have a .onion URL but the `GetHost()` call is failing. Mozilla does not care as there is no decision to be made depending on the *host* but the scheme alone in this check. However, we do care.
Let's look at that from a different angle: the code block we added is essentially a check for a .onion domain: if we don't have one, accept the request otherwise pass it on for further checks. Let's look what we do elsewhere when checking for a .onion domain, e.g. in `IsPotentiallyTrustworthyOnion()`. [There](https://searchfox.org/mozilla-esr68/source/dom/security/nsMixedContentBlocker.cpp#401) we have:
```
nsAutoCString host;
nsresult rv = aURL->GetHost(host);
NS_ENSURE_SUCCESS(rv, false);
return StringEndsWith(host, NS_LITERAL_CSTRING(".onion"));
```
This means if the `GetHost()` check fails we say "no, that's not a .onion". Following that logic we would get to `parentIsOnion = false` in our code block in question and we should `ACCEPT` the request as well in case the `GetHost()` call fails.https://gitlab.torproject.org/legacy/trac/-/issues/34382Don't require M_SYSCALL in sandbox.c2020-06-13T15:53:45ZNick MathewsonDon't require M_SYSCALL in sandbox.cIn sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we ...In sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we don't have it defined can still build with m_syscall.
See also #32904 and #30987Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34381Shellcheck warnings for no-longer-existent contrib scripts2020-06-13T15:53:44ZcShellcheck warnings for no-longer-existent contrib scripts```
% shellcheck --version
ShellCheck - shell script analysis tool
version: 0.7.1
```
Running `make check` results in a few warnings for both `contrib/dist/suse/tor.sh` and `contrib/dist/tor.sh`, namely SC2034 (unused variables) and SC2...```
% shellcheck --version
ShellCheck - shell script analysis tool
version: 0.7.1
```
Running `make check` results in a few warnings for both `contrib/dist/suse/tor.sh` and `contrib/dist/tor.sh`, namely SC2034 (unused variables) and SC2039 (POSIX incompatibilities). If shellcheck is right, then I can gladly go ahead and address these warnings in a PR.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34380Add GSoC and Outreachy interns to GRP_user group2020-06-13T17:02:22ZPili GuerraAdd GSoC and Outreachy interns to GRP_user groupHi,
Can we please get the following trac users added to the GRP_user group?
ayahany
c
HashikD
krona
nicoleiocana
woswos
(Some of these may have been done already...)
Thank you!Hi,
Can we please get the following trac users added to the GRP_user group?
ayahany
c
HashikD
krona
nicoleiocana
woswos
(Some of these may have been done already...)
Thank you!Jens KubiezielJens Kubiezielhttps://gitlab.torproject.org/legacy/trac/-/issues/34379Fix learn more for Onion-Location2020-06-16T01:13:16ZAlex CatarineuFix learn more for Onion-LocationSimilar to #34369, we have to fix the learn more links in the doorhanger and in about:preferences to point to https://tb-manual.torproject.org/[locale]/onion-services/Similar to #34369, we have to fix the learn more links in the doorhanger and in about:preferences to point to https://tb-manual.torproject.org/[locale]/onion-services/Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/34378Port external helper app prompting before opening to Fenix2020-06-15T23:01:25ZGeorg KoppenPort external helper app prompting before opening to FenixIn #26529 we ported the desktop capability to prompt before opening external apps to mobile. We need to redo that proxy-bypass-protection part for Fenix.In #26529 we ported the desktop capability to prompt before opening external apps to mobile. We need to redo that proxy-bypass-protection part for Fenix.https://gitlab.torproject.org/legacy/trac/-/issues/34377Port padlock states for .onion services to Fenix2020-06-16T01:13:16ZGeorg KoppenPort padlock states for .onion services to Fenix#26690 ported the padlock states for onions to mobile. We need to redo that for Fenix.#26690 ported the padlock states for onions to mobile. We need to redo that for Fenix.https://gitlab.torproject.org/legacy/trac/-/issues/34376Space out src/feature/stats/rephist.c2020-06-13T15:53:44ZNeel Chauhanneel@neelc.orgSpace out src/feature/stats/rephist.chttps://gitlab.torproject.org/legacy/trac/-/issues/34375Remove 0.4.1 from git-list-tor-branches.sh and add 0.4.42020-06-13T15:53:44ZNick MathewsonRemove 0.4.1 from git-list-tor-branches.sh and add 0.4.4Now that 0.4.1 is EOL, we can remove it from git-list-tor-branches.Now that 0.4.1 is EOL, we can remove it from git-list-tor-branches.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34374put trac readonly on june 12th 20202020-06-13T17:02:22Zanarcatput trac readonly on june 12th 2020as agreed in the last all-hands meeting, trac will be readonly on june 12th 2020 for the final migration, and will remain so for 6 months, until it is permanently archived and transformed into a redirect to gitlab (#34373).as agreed in the last all-hands meeting, trac will be readonly on june 12th 2020 for the final migration, and will remain so for 6 months, until it is permanently archived and transformed into a redirect to gitlab (#34373).HiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/34373redirect trac.torproject.org to gitlab.torproject.org on dec 12th 20202020-06-13T17:02:22Zanarcatredirect trac.torproject.org to gitlab.torproject.org on dec 12th 2020Once trac is shutdown, redirections from trac.torproject.org needs to be perform to gitlab.torproject.org.
This happens 6 months after trac is put readonly (which is on june 12th) so december 12th 2020.Once trac is shutdown, redirections from trac.torproject.org needs to be perform to gitlab.torproject.org.
This happens 6 months after trac is put readonly (which is on june 12th) so december 12th 2020.Jens KubiezielJens Kubiezielhttps://gitlab.torproject.org/legacy/trac/-/issues/34372Disable GeckoNetworkManager2020-06-16T01:13:15ZMatthew FinkelDisable GeckoNetworkManagerWe have [a patch](https://gitweb.torproject.org/tor-browser.git/commit/mobile/android/geckoview/src/main/java/org/mozilla/geckoview?h=tor-browser-68.9.0esr-10.0-1-build1&id=c010e1cb96eb1baa53e7a938b5af349d07a87b7d) from #25741 that claim...We have [a patch](https://gitweb.torproject.org/tor-browser.git/commit/mobile/android/geckoview/src/main/java/org/mozilla/geckoview?h=tor-browser-68.9.0esr-10.0-1-build1&id=c010e1cb96eb1baa53e7a938b5af349d07a87b7d) from #25741 that claims to disable the GeckoNetworkManager. GK noticed the logic is reversed.
Let's land this in an alpha and then backport it to stable after some testing. It should be mostly harmless.