Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T00:45:56Zhttps://gitlab.torproject.org/legacy/trac/-/issues/25973Backport off-by-one fix in 13520732020-06-16T00:45:56ZGeorg KoppenBackport off-by-one fix in 1352073As a defense in depth we should backport the off-by-one error fix in https://bugzilla.mozilla.org/show_bug.cgi?id=1352073.As a defense in depth we should backport the off-by-one error fix in https://bugzilla.mozilla.org/show_bug.cgi?id=1352073.https://gitlab.torproject.org/legacy/trac/-/issues/25938backport 13347762020-06-16T00:45:52ZArthur Edelsteinbackport 1334776We'd like to backport Mozilla's 1334776We'd like to backport Mozilla's 1334776https://gitlab.torproject.org/legacy/trac/-/issues/25810Backport fixes for Orfox2020-06-16T00:45:34ZGeorg KoppenBackport fixes for OrfoxWe should backport the fix for 1453653 for Orfox. I guess we could just use the ESR52 patch in that ticket.We should backport the fix for 1453653 for Orfox. I guess we could just use the ESR52 patch in that ticket.Igor OliveiraIgor Oliveirahttps://gitlab.torproject.org/legacy/trac/-/issues/25807Can not request bridges from torproject.org (App Engine is broken for moat)2020-06-13T18:29:10ZTracCan not request bridges from torproject.org (App Engine is broken for moat)Can not request bridges from torproject.org , Tor gets stuck at `Contacting BridgeDB. please wait`.
Direct connection to Tor Works.
TorBrowser 8a5
**Trac**:
**Username**: DbryrtfbcbhgfCan not request bridges from torproject.org , Tor gets stuck at `Contacting BridgeDB. please wait`.
Direct connection to Tor Works.
TorBrowser 8a5
**Trac**:
**Username**: Dbryrtfbcbhgfhttps://gitlab.torproject.org/legacy/trac/-/issues/25746git_submodule option doesn't work when a submodule is not in the root directory2020-06-13T17:39:26Zboklmgit_submodule option doesn't work when a submodule is not in the root directoryrbm has the `git_submodule` option to include all submodules in the sources tarball. This option works as expected when all the submodules are located in the root directory, however it fails if one of the submodules is in a sub-directory...rbm has the `git_submodule` option to include all submodules in the sources tarball. This option works as expected when all the submodules are located in the root directory, however it fails if one of the submodules is in a sub-directory.
The reason is that we do this to create .tar files for all the submodules:
```
($stdout, $stderr, $success, $exit_code)
= capture_exec('git', 'submodule', 'foreach',
"git archive --prefix=$project-$version/\$path/"
. " --output=$tmpdir/submodule-\$name.tar \$sha1");
```
We use the submodule name in the output filename inside a temporary directory, which fails when the submodule name contains `/` as it wants to create a file in a directory which does not exist.boklmboklmhttps://gitlab.torproject.org/legacy/trac/-/issues/25721Backport patches for 14487712020-06-16T00:45:22ZGeorg KoppenBackport patches for 1448771Mozilla does not plan to backport the patches for 1448771 but we could to be on the safe side.Mozilla does not plan to backport the patches for 1448771 but we could to be on the safe side.https://gitlab.torproject.org/legacy/trac/-/issues/25710Extract from $rootdir in mingw-w64's setup.2020-06-16T00:45:21ZDavid Fifielddcf@torproject.orgExtract from $rootdir in mingw-w64's setup.This makes it consistent with the setup of gcc and macosx-toolchain.
I encountered this while trying to build go-webrtc with mingw-w64; the build script had already moved into a different directory when it tried to extract mingw-w64, an...This makes it consistent with the setup of gcc and macosx-toolchain.
I encountered this while trying to build go-webrtc with mingw-w64; the build script had already moved into a different directory when it tried to extract mingw-w64, and couldn't find the file.https://gitlab.torproject.org/legacy/trac/-/issues/25481Ship tor in Tor Browser nightly builds on Linux with Rust enabled2020-06-16T00:45:31ZGeorg KoppenShip tor in Tor Browser nightly builds on Linux with Rust enabledWe should test tor with Rust enabled in our Linux nightly builds.We should test tor with Rust enabled in our Linux nightly builds.https://gitlab.torproject.org/legacy/trac/-/issues/25458UI customization half-broken in Tor Browser 8.0a32020-06-16T00:44:23ZTracUI customization half-broken in Tor Browser 8.0a3seen with Tor Browser 8.0a3-build1 on Linux (64 bit)
Changing the UI via the menu entry "Customize" does not work anymore because the customization view closes immediately after opening, so drag-and-drop is impossible. Right-clicking on...seen with Tor Browser 8.0a3-build1 on Linux (64 bit)
Changing the UI via the menu entry "Customize" does not work anymore because the customization view closes immediately after opening, so drag-and-drop is impossible. Right-clicking on a menu entry and selecting "Move to Toolbar" still works, as well as "Move to Menu" for something which was moved to the toolbar.
Maybe #25147 is the reason.
**Trac**:
**Username**: viktorjrichardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/25420Update gcc to 6.4.0 (Windows)2020-06-16T00:44:19ZboklmUpdate gcc to 6.4.0 (Windows) We should build Tor Browser for Windows using gcc 6.4.0. We should build Tor Browser for Windows using gcc 6.4.0.https://gitlab.torproject.org/legacy/trac/-/issues/25331Test from #18912 failing2020-06-16T00:44:08ZArthur EdelsteinTest from #18912 failingWhile preparing to uplift our [patch](https://gitweb.torproject.org/tor-browser.git/patch/?id=36e1b88) for #18912, I rebased it to mozilla-central but found one of the mochitests is failing. I then ran the test in the latest tor-browser....While preparing to uplift our [patch](https://gitweb.torproject.org/tor-browser.git/patch/?id=36e1b88) for #18912, I rebased it to mozilla-central but found one of the mochitests is failing. I then ran the test in the latest tor-browser.git branch (tor-browser-52.6.0esr-8.0-2) and saw the same test failure:
```
<div style="font-family: monospace; white-space: pre-wrap;">
0 INFO TEST-START | Shutdown
1 INFO Passed: 30
2 INFO Failed: 1
3 INFO Todo: 0
4 INFO Mode: non-e10s
5 INFO SimpleTest FINISHED
The following tests failed:
56 INFO TEST-UNEXPECTED-FAIL | toolkit/mozapps/update/tests/chrome/test_0790_check_certPinning_noUpdate.xul | Checking update.errorCode == MOZILLA_PKIX_ERROR_KEY_PINNING_FAILURE - got 2153390067, expected 2153398272
SimpleTest.is@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:271:5
checkErrorCode@chrome://mochitests/content/chrome/toolkit/mozapps/update/tests/chrome/test_0790_check_certPinning_noUpdate.xul:61:3
defaultCallback@chrome://mochitests/content/chrome/toolkit/mozapps/update/tests/chrome/utils.js:429:5
</div>
```
Somehow we're not getting the desired error code.https://gitlab.torproject.org/legacy/trac/-/issues/25304Update gcc to 6.4.0 (Linux)2020-06-16T00:44:03ZboklmUpdate gcc to 6.4.0 (Linux)We should build Tor Browser using gcc 6.4.0.We should build Tor Browser using gcc 6.4.0.https://gitlab.torproject.org/legacy/trac/-/issues/25147Backport of fix shipped in Firefox 58.0.1?2020-06-16T00:43:50ZGeorg KoppenBackport of fix shipped in Firefox 58.0.1?We could think about backporting the sec-critical fix shipped in Firefox 58.0.1:
https://hg.mozilla.org/releases/mozilla-release/rev/c2db4a50dc5c93b44852d9a5201f7ec062ecc6cb
ESR 52 got audited and this issue was not found there. We cou...We could think about backporting the sec-critical fix shipped in Firefox 58.0.1:
https://hg.mozilla.org/releases/mozilla-release/rev/c2db4a50dc5c93b44852d9a5201f7ec062ecc6cb
ESR 52 got audited and this issue was not found there. We could use the backport as a defense-in-depth as it closes out a whole attack vector. The patch is largish, though.richardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/25126about:tor should work on small screens (mobile)2020-06-16T00:43:47ZIgor Oliveiraabout:tor should work on small screens (mobile)Right now the about:tor page doesn't render properly on mobile.Right now the about:tor page doesn't render properly on mobile.https://gitlab.torproject.org/legacy/trac/-/issues/21537Consider ignoring secure cookies for .onion addresses2020-06-24T12:23:18Zmicahmicah@torproject.orgConsider ignoring secure cookies for .onion addressesOne of the main problem points with adding onion services to existing web services has been interaction with secure cookies. Its hard to setup onion services because you need to enable secure cookies some times (over regular network+TLS)...One of the main problem points with adding onion services to existing web services has been interaction with secure cookies. Its hard to setup onion services because you need to enable secure cookies some times (over regular network+TLS) and disable them other times (over .onion network, without TLS). Right now you have to make a trade-off: work well with .onions, or work well with everyone else. This is an unfortunate trade-off.
It is considered a best practice that every web developer is told to do, but its a best practice that doesn't work if you want to run an onion site. Running an onion site should not force you to violate established web application development best practices.
The idea of "secure cookies" is that they prevent you from leaking your cookie information over an insecure connection. There are a lot of ways you can leak your cookie info over an insecure connection:
. dont have hsts setup
. running an application server that sets the cookie before it redirects to https
. or your server is not setup to redirect everything to https
Using "secure cookies" allows the application (regardless of how it is run, or what intermediaries are in between), to make sure that the browser doesn't screw this up. It tells the browser to never submit the cookie over plaintext. Many frameworks have this set by default (such as Rails). Some applications, such as java/tomcat have as part of the stack the cookie setting that happens before that does the redirect to https.
The "secure cookies" spec is just a "suggestion" to the browser, so TBB is free to ignore them, and I think that maybe it should do so for .onion sites.
As an example, if a user goes to https://example.com the first response back sends back a cookie with nothing but a session id. If you then login, you now have a sessionid that is privileged and associated with your account. If you then close that tab, but then realize you needed to do something else, so you open a new tab and go to http://example.com (NB: no https). If the site did not mark the original cookies as 'secure', then the browser will submit in that initial first request the cookie it had previously saved and it will send it over the cleartext channel before the webserver can redirect to the secured site. With the secure cookies flag set, the browser will not send the cookie until the TLS connection is up. This doesn't matter if you are going over onion services because the connection is already wrapped in TLS, and it also doesn't matter if the site has HSTS, because the second visit will go to https by default in that scenario.
So what are the options?
. Ignore secure cookie flags for .onions
. Ignore tls verification for onions
Either one would increase the security properties of onion and non onions, unfortunately the second one would not be appreciated by sites that have actually paid for a valid .onion cert.
Pretty much every Rails application suffers with TBB because of this problem, I'm pretty sure other frameworks also suffer from this. Fixing this would fix a large number of tor problems related to this.
I'm unsure of the broader implications of this, which is why I wanted to open this for discussion.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/20302FTE compilation in our gitian setup is broken for Windows with GCC 6.2.02020-06-13T07:28:24ZGeorg KoppenFTE compilation in our gitian setup is broken for Windows with GCC 6.2.0After #13893 landed (bump mingw-w64 and GCC to 6.2.0) it turns out that FTE compilation is broken:
```
+ make
wine /home/ubuntu/install/python/python.exe setup.py build_ext -c mingw32
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
...After #13893 landed (bump mingw-w64 and GCC to 6.2.0) it turns out that FTE compilation is broken:
```
+ make
wine /home/ubuntu/install/python/python.exe setup.py build_ext -c mingw32
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
running build_ext
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
building 'fte.cDFA' extension
creating build
creating build\temp.win32-2.7
creating build\temp.win32-2.7\Release
creating build\temp.win32-2.7\Release\fte
C:\windows\gcc.exe -mno-cygwin -mdll -O -Wall -Ifte -Ithirdparty/gmp/include -IZ:\home\ubuntu\install\python\include -IZ:\home\ubuntu\install\python\PC -c fte/rank_unrank.cc -o build\temp.win32-2.7\Release\fte\rank_unrank.o -O3 -fPIC
Exception WindowsError: (6, 'Invalid handle') in <bound method Popen.__del__ of <subprocess.Popen object at 0x00159130>> ignored
C:\windows\gcc.exe -mno-cygwin -mdll -O -Wall -Ifte -Ithirdparty/gmp/include -IZ:\home\ubuntu\install\python\include -IZ:\home\ubuntu\install\python\PC -c fte/cDFA.cc -o build\temp.win32-2.7\Release\fte\cdfa.o -O3 -fPIC
In file included from /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include/c++/6.2.0/math.h:36:0,
from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/install/python/include/pyport.h:325,
from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/install/python/include/Python.h:58,
from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/build/libfte/fte/cDFA.cc:1:
/home/ubuntu/install/mingw-w64/i686-w64-mingw32/include/c++/6.2.0/cmath:1133:11: error: '::hypot' has not been declared
using ::hypot;
^~~~~
In file included from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/install/python/include/Python.h:80:0,
from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/build/libfte/fte/cDFA.cc:1:
/home/ubuntu/.wine/dosdevices/z:/home/ubuntu/build/libfte/fte/cDFA.cc: In function 'void initcDFA()':
/home/ubuntu/.wine/dosdevices/z:/home/ubuntu/install/python/include/object.h:767:22: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
((PyObject*)(op))->ob_refcnt++)
^
/home/ubuntu/.wine/dosdevices/z:/home/ubuntu/build/libfte/fte/cDFA.cc:273:5: note: in expansion of macro 'Py_INCREF'
Py_INCREF(&DFAType);
^~~~~~~~~
Exception WindowsError: (6, 'Invalid handle') in <bound method Popen.__del__ of <subprocess.Popen object at 0x00159150>> ignored
error: command 'gcc' failed with exit status 1
fixme:msvcrt:__clean_type_info_names_internal (0x1d114810) stub
fixme:msvcrt:__clean_type_info_names_internal (0xa254f0) stub
fixme:msvcrt:__clean_type_info_names_internal (0x100d4460) stub
fixme:msvcrt:__clean_type_info_names_internal (0x42ba30) stub
fixme:msvcrt:__clean_type_info_names_internal (0x1e24c178) stub
make: *** [fte/cDFA.pyd] Error 1
```kpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/20283Tor Browser should run without a `/proc` filesystem.2020-06-16T00:47:59ZYawning AngelTor Browser should run without a `/proc` filesystem.Currently Tor Browser crashes immediately on startup if a proc filesystem is not mounted on `/proc`. This also affects the upstream firefox code, so it technically is a Mozilla bug.
```
too much recursion
Segmentation fault (core dumpe...Currently Tor Browser crashes immediately on startup if a proc filesystem is not mounted on `/proc`. This also affects the upstream firefox code, so it technically is a Mozilla bug.
```
too much recursion
Segmentation fault (core dumped)
```
`/proc` contains a large amount of information about the host system that can be used to fingerprint/identify users and additionally historically has been the source or part of many kernel security problems.
While this problem can be mitigated by a MAC system (eg: AppArmor) to constrain what Firefox can access under `/proc`, the ideal fix is for Firefox to support running without `/proc`, while degrading gracefully (there is no truly ubiquitous MAC system available on all common Linux distributions by default, and the problem is severe enough that it should be resolved correctly).richardrichard