Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:27Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34130Tor won't start with seccomp sandbox when compiled with --enable-nss2020-06-13T15:53:27ZJigsaw52Tor won't start with seccomp sandbox when compiled with --enable-nssAfter compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-st...After compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-stable, NSS 3.35, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3.
May 06 21:47:46.198 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 06 21:47:46.198 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 06 21:47:46.198 [notice] Read configuration file "/home/daniel/Desktop/torrc_sandbox".
May 06 21:47:46.200 [notice] Opening Socks listener on 127.0.0.1:9050
May 06 21:47:46.200 [notice] Opened Socks listener on 127.0.0.1:9050
May 06 21:47:46.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
May 06 21:47:46.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
May 06 21:47:46.000 [warn] TLS error PR_NO_ACCESS_RIGHTS_ERROR while constructing a client TLS context: Access Denied
May 06 21:47:46.000 [err] Error creating TLS context for Tor client.
May 06 21:47:46.000 [err] Error initializing keys; exiting
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33757Fix log message when multiple tors try the same data directory2020-06-13T15:52:37ZteorFix log message when multiple tors try the same data directoryWhen a user launches two tor processes in the same data directory, they get these confusing logs:
```
Mar 29 17:45:08.000 [warn] It looks like another Tor process is running with the same data directory. Waiting 5 seconds to see if it g...When a user launches two tor processes in the same data directory, they get these confusing logs:
```
Mar 29 17:45:08.000 [warn] It looks like another Tor process is running with the same data directory. Waiting 5 seconds to see if it goes away.
Mar 29 17:45:13.000 [err] No, it's still there. Exiting.
Mar 29 17:45:13.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.4.2.7 )
Mar 29 17:45:13.000 [err] Reading config failed--see warnings above.
Mar 29 19:55:41.000 [notice] Catching signal TERM, exiting cleanly.
```
Full logs:
https://lists.torproject.org/pipermail/tor-relays/2020-March/018306.html
I don't think the bug log should be there.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/32961Backport the diagnostic logs for is_possible_guard crash2020-06-13T15:49:59ZteorBackport the diagnostic logs for is_possible_guard crashLet's backport this PR to diagnose the #32868 is_possible_guard crash:
* 0.3.5: https://github.com/torproject/tor/pull/1661Let's backport this PR to diagnose the #32868 is_possible_guard crash:
* 0.3.5: https://github.com/torproject/tor/pull/1661Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32165On first boot, Tor mistakenly tells me "The current consensus has no exit nodes"2020-06-13T15:47:00ZRoger DingledineOn first boot, Tor mistakenly tells me "The current consensus has no exit nodes"Starting up 0.4.3.0-alpha-dev (git-71daad1692bc3f24) without any cached-* files in my DataDirectory, I get:
```
Oct 20 04:44:56.026 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Oct 20 04:44:56.636 [notice] ...Starting up 0.4.3.0-alpha-dev (git-71daad1692bc3f24) without any cached-* files in my DataDirectory, I get:
```
Oct 20 04:44:56.026 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Oct 20 04:44:56.636 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Oct 20 04:44:56.758 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
Oct 20 04:44:56.936 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
Oct 20 04:44:56.936 [notice] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
Oct 20 04:44:56.936 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/5841, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
Oct 20 04:44:57.337 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
Oct 20 04:44:57.592 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.
Oct 20 04:44:58.178 [notice] Bootstrapped 58% (loading_descriptors): Loading relay descriptors
```
It's that "The current consensus has no exit nodes." line that is out of place.Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31736Stop using mutex_destroy(), when multiple threads can still access the mutex2020-06-13T15:45:36ZteorStop using mutex_destroy(), when multiple threads can still access the mutexPart of #31614, alternative to #31735.
If we can't join all the threads before destroying a mutex (#31735), and we can't otherwise prevent multiple thread access, we should stop destroying that mutex. (Because destroying a locked thread...Part of #31614, alternative to #31735.
If we can't join all the threads before destroying a mutex (#31735), and we can't otherwise prevent multiple thread access, we should stop destroying that mutex. (Because destroying a locked thread invokes undefined behaviour.)
There may be some other pattern that helps us destroy all but one mutex. But that involves a "mutex-destruction" mutex. Which is terribly complex.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31644NumPrimaryGuards is set to 6, but the log file keep reports that is missing d...2020-06-13T15:45:17Zs7rNumPrimaryGuards is set to 6, but the log file keep reports that is missing descriptors for 1/3 of our primary entry guardsA Tor instance running with `NumPrimaryGuards = 6` and `NumEntryGuards = 2` will report:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of o...A Tor instance running with `NumPrimaryGuards = 6` and `NumEntryGuards = 2` will report:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
Sep 05 03:22:50.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
```
We expect to run with 6 primary entry guards and use 2/6 of them all the time, so it should complain about missing descriptors for 1/6 or our primary entry guards. Or maybe this param is not processed correctly and updated in the state file.
When `NumPrimaryGuards` changes its value, we should sample more guards as primary in the existent state file, or create one if it doesn't exist with the right number of primary guards.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31614Implement clean_up_backtrace_handler()2020-06-13T15:45:05ZteorImplement clean_up_backtrace_handler()Split off #31594:
clean_up_backtrace_handler() doesn't do anything, but it should:
* disable backtrace signal handlers
* destroy the backtrace mutex (regression to #21788)Split off #31594:
clean_up_backtrace_handler() doesn't do anything, but it should:
* disable backtrace signal handlers
* destroy the backtrace mutex (regression to #21788)Tor: 0.4.1.x-finalteorteor