The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-02-03T19:07:02Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34144user.js is ignored after Tor (part) starts2022-02-03T19:07:02ZTracuser.js is ignored after Tor (part) startsSteps to reproduce:
1)
create file Browser/TorBrowser/Data/Browser/profile.default/user.js with contents:
// blank 1st line
user_pref("javascript.enabled", false);
user_pref("app.update.auto", false);
2)
Start Tor and wait for Tor con...Steps to reproduce:
1)
create file Browser/TorBrowser/Data/Browser/profile.default/user.js with contents:
// blank 1st line
user_pref("javascript.enabled", false);
user_pref("app.update.auto", false);
2)
Start Tor and wait for Tor connection pop up.
3)
Make sure user.js was included:
$ grep -e app.update.auto -e javascript.enabled Browser/TorBrowser/Data/Browser/profile.default/prefs.js
user_pref("app.update.auto", false);
user_pref("javascript.enabled", false);
4)
Click "Connect" to and wait for browser to start
5)
Check prefs.js again, and javascript.enabled is gone
$ grep -e app.update.auto -e javascript.enabled Browser/TorBrowser/Data/Browser/profile.default/prefs.js
user_pref("app.update.auto", false);
Expected behaviour:
According to Firefox documentation user.js may override any preference. There's a warning that plugins that ignore this won't pass certification.
After Tor has finished playing with the configuration it must apply the user.js again.
With the current setup there doesn't seem to be a way to start the Tor browser with javascript.enabled set to false and allow the user to change it to true if that want.
Background:
We are running Tor inside docker, so constantly downloading updates until we can update the docker image seems like unnecessary waste of precious onion bandwidth.
With app.update.auto set to false, we get a pop up which says there is a new version available so we can update in our own time.
With the current setup there doesn't seem to be a way to start the Tor browser with javascript.enabled set to false and allow the user to change it to true if that want.
**Trac**:
**Username**: davidnewcombhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20863Unittest fail on master: FAIL src/test/test_controller.c:190: assert(!cfg)2020-06-27T13:57:41ZGeorge KadianakisUnittest fail on master: FAIL src/test/test_controller.c:190: assert(!cfg)On latest master (e6facbfe7abc50de374300ecd83873ead65b4b04) the following test fails on my box:
```
control/rend_service_parse_port_config:
FAIL src/test/test_controller.c:190: assert(!cfg)
[rend_service_parse_port_config FAILED]
```On latest master (e6facbfe7abc50de374300ecd83873ead65b4b04) the following test fails on my box:
```
control/rend_service_parse_port_config:
FAIL src/test/test_controller.c:190: assert(!cfg)
[rend_service_parse_port_config FAILED]
```Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34145Investigate fallout from transitioning to 77.0b12020-06-27T14:31:38ZGeorg KoppenInvestigate fallout from transitioning to 77.0b1Compilation is busted with our patches based on 77.0b1. This is the bug to investigate this.Compilation is busted with our patches based on 77.0b1. This is the bug to investigate this.https://gitlab.torproject.org/tpo/core/tor/-/issues/20864Minor fixes to test_single_onion_poisoning2020-06-27T13:57:41ZteorMinor fixes to test_single_onion_poisoningWhen I wrote legacy/trac#20638, the unit test had some subtle bugs:
* a missed return value check in a unit test,
* a double-free (well, two double-frees),
* an inconsistent allocation-free construction that would be easy to break in fut...When I wrote legacy/trac#20638, the unit test had some subtle bugs:
* a missed return value check in a unit test,
* a double-free (well, two double-frees),
* an inconsistent allocation-free construction that would be easy to break in future.
I also want to move a comment.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20865Tor 0.2.8.10 breaks compilation on macOS Sierra2020-06-27T13:57:41ZteorTor 0.2.8.10 breaks compilation on macOS SierraWe forgot to backport the sys/random.h header include and its check.
This means that tor 0.2.8.10 compiles on pre-sierra systems, but not on sierra itself.We forgot to backport the sys/random.h header include and its check.
This means that tor 0.2.8.10 compiles on pre-sierra systems, but not on sierra itself.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34149Revert the "fix" for OpenSSL CVE-2019-15522020-06-27T14:31:38ZcypherpunksRevert the "fix" for OpenSSL CVE-2019-1552If you think you are not vulnerable (ticket:31383#comment:16) and close legacy/trac#31383 again and again. Then revert your still-doesn't-fix-anything patch https://gitweb.torproject.org/builders/tor-browser-build.git/diff/?id=abdfbfdb3f...If you think you are not vulnerable (ticket:31383#comment:16) and close legacy/trac#31383 again and again. Then revert your still-doesn't-fix-anything patch https://gitweb.torproject.org/builders/tor-browser-build.git/diff/?id=abdfbfdb3f4122300c3f3f5e745af1c74a559102https://gitlab.torproject.org/tpo/core/tor/-/issues/20868fails to build on arm2020-06-27T13:57:41Zweasel (Peter Palfrader)fails to build on armOn arm and armhf, with openssl 1.1:
```
gcc -DHAVE_CONFIG_H -I. -I.. -I../src/ext -Isrc/ext -I../src/ext/trunnel -I../src/trunnel -I../src/common -Isrc/common -I../src/ext/trunnel -I../src/trunnel -I../src/or -Isrc/or -DSHARE_DATADIR="\...On arm and armhf, with openssl 1.1:
```
gcc -DHAVE_CONFIG_H -I. -I.. -I../src/ext -Isrc/ext -I../src/ext/trunnel -I../src/trunnel -I../src/common -Isrc/common -I../src/ext/trunnel -I../src/trunnel -I../src/or -Isrc/or -DSHARE_DATADIR="\"/usr/share\"" -DLOCALSTATEDIR="\"/var\"" -DBINDIR="\"/usr/bin\"" -Wdate-time -D_FORTIFY_SOURCE=2 -I../src/common -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector -fwrapv --param ssp-buffer-size=1 -fPIE -fasynchronous-unwind-tables -Wall -fno-strict-aliasing -W -Wfloat-equal -Wundef -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wbad-function-cast -Wswitch-enum -Winit-self -Wmissing-field-initializers -Wold-style-definition -Waddress -Wmissing-noreturn -Wstrict-overflow=1 -Wnormalized=id -Woverride-init -Wextra -Warray-bounds -Wlogical-op -c -o src/common/crypto.o ../src/common/crypto.c
../src/common/aes.c:158:20: error: field 'evp' has incomplete type
EVP_CIPHER_CTX evp;
^~~
../src/common/aes.c: In function 'evaluate_ctr_for_aes':
../src/common/aes.c:254:5: warning: implicit declaration of function 'AES_ctr128_encrypt' [-Wimplicit-function-declaration]
AES_ctr128_encrypt(&zero[i], &output[i], 1, &key, ivec, ivec_tmp, &pos);
^~~~~~~~~~~~~~~~~~
../src/common/aes.c:254:5: warning: nested extern declaration of 'AES_ctr128_encrypt' [-Wnested-externs]
Makefile:3347: recipe for target 'src/common/aes.o' failed
```
https://volatile.noreply.org/2016-12-02-JueousgnOYk/tor_0.2.8.10-1_armel-2016-12-02T182943Z.build has a more complete log of a (different) build.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34156Tor browser won't load on Win10.0.183632022-06-01T07:49:41ZTracTor browser won't load on Win10.0.18363Tor unexpectedly exited message.
Attempt to copy log to clipboard results in 0 messages copied to clipboard.
Button to restart Tor presented...hitting it result in same issue again.
Last line of box reports:
For assistance, visit support...Tor unexpectedly exited message.
Attempt to copy log to clipboard results in 0 messages copied to clipboard.
Button to restart Tor presented...hitting it result in same issue again.
Last line of box reports:
For assistance, visit support.torproject.org/#connectingtotor
**Trac**:
**Username**: oldman63https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34157Backport Patch for Firefox Bug 1511941 - privacy.resistfingerprinting perform...2020-06-27T14:31:38ZTracBackport Patch for Firefox Bug 1511941 - privacy.resistfingerprinting performance API spoofing breaks vimeo.comFirefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1511941
I have attached a backported (to ESR68) version of my patch.
**Trac**:
**Username**: sankethFirefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1511941
I have attached a backported (to ESR68) version of my patch.
**Trac**:
**Username**: sankethhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20872option to build non-standard code paths on x862022-06-17T18:11:20Zweasel (Peter Palfrader)option to build non-standard code paths on x86legacy/trac#20868 is a case where one code path gets almost always built on x86, and another is used everywhere else.
This means that we don't notice build or test failures on that other code path.
Should we have options to use the alt...legacy/trac#20868 is a case where one code path gets almost always built on x86, and another is used everywhere else.
This means that we don't notice build or test failures on that other code path.
Should we have options to use the alternate path even on x86, so we can build and run tests on our CI using fast machines?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34178Implement new UI changes as determined in O2.12020-11-12T14:46:54ZMatthew FinkelImplement new UI changes as determined in O2.1Update the Tor Browser for Android codebase to use Fenix instead of Fennec.
- [x] ["Only Private Browsing Mode" on Android](tpo/applications/fenix#40006)
- [x] [Modify Fenix menu items](tpo/applications/fenix#40007)
- [x] fenix#40026
...Update the Tor Browser for Android codebase to use Fenix instead of Fennec.
- [x] ["Only Private Browsing Mode" on Android](tpo/applications/fenix#40006)
- [x] [Modify Fenix menu items](tpo/applications/fenix#40007)
- [x] fenix#40026
- [x] fenix#40028Sponsor 58 - Tor Browser Security, Performance, & Usability Improvementshttps://gitlab.torproject.org/tpo/core/tor/-/issues/20874ReachableAddresses adds an extra reject *:* on every SAVECONF2020-06-27T13:57:41ZteorReachableAddresses adds an extra reject *:* on every SAVECONFTo fix this issue, we can do two things:
1) We should add the reject *:* to a copy of the list after it has been parsed in parse_reachable_addresses() using append_exit_policy_string(), rather than adding it to the option itself in opti...To fix this issue, we can do two things:
1) We should add the reject *:* to a copy of the list after it has been parsed in parse_reachable_addresses() using append_exit_policy_string(), rather than adding it to the option itself in options_validate().
2) We might also want to call exit_policy_remove_redundancies() on the parsed policy, so that long policies with redundancies are handled more efficiently. This is only likely to ever matter on busy hidden services.Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/20875Non-fatal assertion !(delay == INT_MAX) failed in next_random_exponential_del...2020-06-27T13:57:40ZRoger DingledineNon-fatal assertion !(delay == INT_MAX) failed in next_random_exponential_delay at src/or/directory.c:3792```
Dec 03 19:59:44.346 [info] Received http status code 304 ("Not modified") from server '149.56.233.142:443' while fetching consensus directory.
Dec 03 19:59:44.346 [debug] conn_close_if_marked(): Cleaning up connection (fd -1).
Dec 03...```
Dec 03 19:59:44.346 [info] Received http status code 304 ("Not modified") from server '149.56.233.142:443' while fetching consensus directory.
Dec 03 19:59:44.346 [debug] conn_close_if_marked(): Cleaning up connection (fd -1).
Dec 03 19:59:44.346 [warn] tor_bug_occurred_(): Bug: src/or/directory.c:3792: next_random_exponential_delay: Non-fatal assertion !(delay == INT_MAX) failed. (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: Non-fatal assertion !(delay == INT_MAX) failed in next_random_exponential_delay at src/or/directory.c:3792. Stack trace: (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(log_backtrace+0x42) [0x7f8e125a6562] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(tor_bug_occurred_+0xb7) [0x7f8e125bf117] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(+0x116615) [0x7f8e12571615] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(download_status_increment_failure+0xa6) [0x7f8e12575f06] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(networkstatus_consensus_download_failed+0x66) [0x7f8e124a9746] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(connection_dir_about_to_close+0x24f) [0x7f8e1257a36f] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(+0x4236d) [0x7f8e1249d36d] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(+0x42b0c) [0x7f8e1249db0c] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f8e11ae43dc] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(do_main_loop+0x234) [0x7f8e1249f1e4] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(tor_main+0x1c25) [0x7f8e124a2935] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(main+0x19) [0x7f8e1249aac9] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f8e10ab5b45] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [warn] Bug: src/or/tor(+0x3fb19) [0x7f8e1249ab19] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
Dec 03 19:59:44.347 [debug] connection_remove(): removing socket -1 (type Directory), n_conns now 12
```
This is an ordinary Tor client minding its own business. (Sorry that it is a few weeks before the 0.2.9.6-rc release.)Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20885Portions of the tor.1 man page and html doc formatted incorrectly2021-07-22T16:22:54ZTracPortions of the tor.1 man page and html doc formatted incorrectlySome portions of the tor.1 doc don't join paragraphs correctly, leading to strange output styles, especially in html view, which appears to default to <pre> blocks when asciidoc is confused by the syntax.
**Trac**:
**Username**: jryansSome portions of the tor.1 doc don't join paragraphs correctly, leading to strange output styles, especially in html view, which appears to default to <pre> blocks when asciidoc is confused by the syntax.
**Trac**:
**Username**: jryansTor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20887DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead2021-09-16T14:33:04ZteorDIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d insteadA FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this ...A FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this functionality by setting the DirCache option to 0
```
So we should print the macro value the same way we do every other value, using "%d" in the string, and passing it as an argument.
(This macro changed name in legacy/trac#20684.)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40013Make sure we ship regular release builds with proper non-esr mozconfig files2022-07-09T18:30:57ZGeorg KoppenMake sure we ship regular release builds with proper non-esr mozconfig filesAmong other differences there are some tweaks in used mozconfig files
and configurations that set regular release from esr release builds
apart. We should make sure the mozconfig files we use for building Fenix
reflect that.
We got remi...Among other differences there are some tweaks in used mozconfig files
and configurations that set regular release from esr release builds
apart. We should make sure the mozconfig files we use for building Fenix
reflect that.
We got reminded at that fact by looking closer at the fix that landed in
https://bugzilla.mozilla.org/show_bug.cgi?id=1308251 and wondering
whether `MOZ_REQUIRE_SIGNING` is set or not. It's not the case for the
esr channel but it is set for regular release builds.
We should try to collect the differences and adjust the mozconfig
files/build environment for non-esr builds accordingly where needed.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34188Cleanup extensions.* prefs2022-10-03T14:11:44ZAlex CatarineuCleanup extensions.* prefsThere are several `extensions.*` prefs that are not needed anymore, such as `extensions.enabledAddons`, `extensions.enabledItems` or `extensions.legacy.exceptions`. We should take a look and remove the ones we do not need anymore.There are several `extensions.*` prefs that are not needed anymore, such as `extensions.enabledAddons`, `extensions.enabledItems` or `extensions.legacy.exceptions`. We should take a look and remove the ones we do not need anymore.https://gitlab.torproject.org/tpo/core/tor/-/issues/20893Add a fuzzing harness for Tor2020-06-27T13:57:40ZteorAdd a fuzzing harness for TorI have a branch for this, we held off on releasing it publicly because it made the underlying bug in legacy/trac#20384 obvious.
Now we've had time for people to upgrade to 0.2.8.9 (and various other patched versions), we can release the...I have a branch for this, we held off on releasing it publicly because it made the underlying bug in legacy/trac#20384 obvious.
Now we've had time for people to upgrade to 0.2.8.9 (and various other patched versions), we can release the fuzzing code.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20894Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http (TROVE-2016-10-...2020-06-27T13:57:40ZteorResolve read-off-end-of-buffer on atoi in fetch_from_buf_http (TROVE-2016-10-001)Since we're releasing the fuzzing code (legacy/trac#20893) that reveals the underlying bug in legacy/trac#20384, we should also fix that bug.
It's entirely safe to fix the bug in 0.3.0, because the mitigation applied in legacy/trac#2038...Since we're releasing the fuzzing code (legacy/trac#20893) that reveals the underlying bug in legacy/trac#20384, we should also fix that bug.
It's entirely safe to fix the bug in 0.3.0, because the mitigation applied in legacy/trac#20384 works.
When we fix it, we should credit:
Discovered by fuzzing using afl: http://lcamtuf.coredump.cx/afl/
It would be nice to email the maintainer with this ticket number and let them know, so they can add it to their gallery.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34192It Just Does Not Work2021-07-09T14:43:41ZTracIt Just Does Not WorkTor worked like a breeze for me a few months ago. Now I cannot even get it to start.
Something is serious fucked up with this latest version of the browser, and there is **no good information out there** on what to do about it. Gibb...Tor worked like a breeze for me a few months ago. Now I cannot even get it to start.
Something is serious fucked up with this latest version of the browser, and there is **no good information out there** on what to do about it. Gibberish and nonsense.
Please post a **plain-English** solution to this problem.
No, I do not use a proxy, I am not in a country where Tor is censored, and there is absolutely nothing wrong with my system clock.
OS: **Windows 7**
Tor Version: **9.0.10**
Log:
5/12/20, 13:23:34.321 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
5/12/20, 13:23:34.321 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
5/12/20, 13:23:34.321 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
5/12/20, 13:23:34.322 [NOTICE] Opening Socks listener on 127.0.0.1:9150
5/12/20, 13:23:34.322 [NOTICE] Opened Socks listener on 127.0.0.1:9150
5/12/20, 13:23:34.322 [NOTICE] Renaming old configuration file to "E:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc.orig.1"
5/12/20, 13:23:34.322 [NOTICE] Bootstrapped 5% (conn): Connecting to a relay
5/12/20, 13:24:58.291 [WARN] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 10; recommendation warn; host 847B1F850344D7876491A54892F904934E4EB85D at 86.59.21.38:443)
5/12/20, 13:24:58.291 [WARN] 9 connections have failed:
5/12/20, 13:24:58.291 [WARN] 9 connections died in state connect()ing with SSL state (No SSL object)
5/12/20, 13:24:58.299 [WARN] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 11; recommendation warn; host FFA72BD683BC2FCF988356E6BEC1E490F313FB07 at 193.11.164.243:9001)
5/12/20, 13:24:58.299 [WARN] 10 connections have failed:
5/12/20, 13:24:58.299 [WARN] 10 connections died in state connect()ing with SSL state (No SSL object)
5/12/20, 13:24:58.299 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
5/12/20, 13:24:58.299 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
5/12/20, 13:24:59.290 [NOTICE] Delaying directory fetches: DisableNetwork is set.
**Trac**:
**Username**: WR Smith