Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-01-28T17:58:13Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33346Seccomp soft fail (no write) in 0.4.2.62021-01-28T17:58:13ZTracSeccomp soft fail (no write) in 0.4.2.6I've upgraded to 0.4.2.6 (as a good software user, but also because I noticed the seccomp changes).
Tor successfully starts with seccomp, but 'soft fails' because it can't write to its data directory (here: /var/lib/tor/data). Tor has p...I've upgraded to 0.4.2.6 (as a good software user, but also because I noticed the seccomp changes).
Tor successfully starts with seccomp, but 'soft fails' because it can't write to its data directory (here: /var/lib/tor/data). Tor has permissions to write to this directory - fine with Sandbox 0.
Log:
```
# cat /var/log/tor/log
Feb 16 00:46:56.000 [notice] Tor 0.4.2.6 opening new log file.
Feb 16 00:46:56.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Feb 16 00:46:57.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Feb 16 00:46:57.000 [notice] Bootstrapped 0% (starting): Starting
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-certs": Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/unverified-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-microdesc-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/unverified-microdesc-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-microdescs" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-microdescs.new": Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-descriptors" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-extrainfo" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [notice] Starting with guard context "default"
Feb 16 00:46:58.000 [warn] Couldn't open "/var/lib/tor/data/state.tmp" (/var/lib/tor/data/state) for writing: Operation not permitted
Feb 16 00:46:58.000 [warn] Unable to write state to file "/var/lib/tor/data/state"; will try again later
Feb 16 00:46:58.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Feb 16 00:46:58.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Feb 16 00:46:58.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Feb 16 00:46:58.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Feb 16 00:46:58.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Feb 16 00:46:58.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Feb 16 00:46:58.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Feb 16 00:46:59.000 [warn] Couldn't open "/var/lib/tor/data/unverified-microdesc-consensus.tmp" (/var/lib/tor/data/unverified-microdesc-consensus) for writing: Operation not permitted
Feb 16 00:46:59.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Feb 16 00:46:59.000 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
Feb 16 00:46:59.000 [warn] Couldn't open "/var/lib/tor/data/cached-certs.tmp" (/var/lib/tor/data/cached-certs) for writing: Operation not permitted
Feb 16 00:46:59.000 [warn] Error writing certificates to disk.
Feb 16 00:46:59.000 [warn] Could not open "/var/lib/tor/data/unverified-microdesc-consensus" for mmap(): Operation not permitted
Feb 16 00:46:59.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
```
#### Appendix
##### Environment
```
Tor: 0.4.2.6
OS: Gentoo arm64
Hardware: Raspberry Pi 4
Kernel: 4.19.102-v8+ (RPi base)
```
##### Other info
When running 0.4.2.5, I experienced a crash with seccomp (possibly related to legacy/trac#27315)?
```
# tor
Feb 16 00:37:42.963 [notice] Tor 0.4.2.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Feb 16 00:37:42.963 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 16 00:37:42.963 [notice] Read configuration file "/etc/tor/torrc".
Feb 16 00:37:42.966 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 16 00:37:42.966 [notice] Opened Socks listener on 127.0.0.1:9050
============================================================ T= 1581813463
(Sandbox) Caught a bad syscall attempt (syscall unlinkat)
tor(+0x1cd714)[0x5571820714]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x7f8bde0658]
/lib64/libc.so.6(unlink+0x30)[0x7f8b8058d8]
tor(run_tor_main_loop+0x74)[0x55716ae874]
tor(tor_run_main+0x11c)[0x55716aead4]
tor(tor_main+0x50)[0x55716ad458]
tor(main+0x24)[0x55716acf74]
/lib64/libc.so.6(__libc_start_main+0xe4)[0x7f8b758cac]
tor(+0x59fd0)[0x55716acfd0]
```
**Trac**:
**Username**: subjectfrostingTor: 0.3.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/33354Warning: Padding negotiated cell from wrong hop on circuit2020-06-27T13:48:12ZteorWarning: Padding negotiated cell from wrong hop on circuitRunning chutney's single-onion-v23 network, I see the following warnings:
```
Warning: Padding negotiated cell from wrong hop on circuit
Warning: Received circuit padding stop command for unknown machine
```
These chutney networks are r...Running chutney's single-onion-v23 network, I see the following warnings:
```
Warning: Padding negotiated cell from wrong hop on circuit
Warning: Received circuit padding stop command for unknown machine
```
These chutney networks are running 0.4.4.0-alpha-dev (f231827946).
These warnings appear to be timing-dependent, they don't happen all the time.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33361relay: Warn about the lack of ContactInfo and the consequence2020-11-04T14:18:22ZDavid Gouletdgoulet@torproject.orgrelay: Warn about the lack of ContactInfo and the consequenceThe network health team (including bad relays) as been rejecting group of relays more and more that do not have their `ContactInfo` or/and `MyFamily` set (for a group of relays from the same operator).
These are for safety and health pu...The network health team (including bad relays) as been rejecting group of relays more and more that do not have their `ContactInfo` or/and `MyFamily` set (for a group of relays from the same operator).
These are for safety and health purposes of the network. See the relay guidelines for that.
That being said, we should improve the log notice that an operator get when failing to set `ContactInfo` to a warning and adding a sentence that says they might get rejected from the network due to a lack of valid responsive `ContactInfo`.
I would argue that this needs a backport for our maintained versions. Please, let me know if not agreeing with thatTor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33366Disable dns.c when relay mode is disabled2020-06-27T13:48:12ZNick MathewsonDisable dns.c when relay mode is disabledTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33368Don't compile ext_orport.c when relay mode is disabled.2020-06-27T13:48:11ZNick MathewsonDon't compile ext_orport.c when relay mode is disabled.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33370Don't build selftest.c when relay mode is disabled2020-06-27T13:48:11ZNick MathewsonDon't build selftest.c when relay mode is disabledTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33374Fix unicode warnings in practracker using python 22020-06-27T13:48:10ZteorFix unicode warnings in practracker using python 2When I run practracker using python 2, I get the following unicode warning:
```
$ scripts/maint/practracker/practracker.py --regen-overbroad
Traceback (most recent call last):
File "scripts/maint/practracker/practracker.py", line 324, ...When I run practracker using python 2, I get the following unicode warning:
```
$ scripts/maint/practracker/practracker.py --regen-overbroad
Traceback (most recent call last):
File "scripts/maint/practracker/practracker.py", line 324, in <module>
main(sys.argv)
File "scripts/maint/practracker/practracker.py", line 268, in main
for item in filt.filter(consider_all_metrics(files_list)):
File "/Users/hyper/dev/tor/scripts/maint/practracker/problem.py", line 147, in filter
for item in iter(sequence):
File "scripts/maint/practracker/practracker.py", line 110, in consider_all_metrics
for item in consider_metrics_for_file(fname, f):
File "scripts/maint/practracker/practracker.py", line 134, in consider_metrics_for_file
for item in consider_function_size(fname, f):
File "scripts/maint/practracker/practracker.py", line 91, in consider_function_size
for name, lines in metrics.get_function_lines(f):
File "/Users/hyper/dev/tor/scripts/maint/practracker/metrics.py", line 58, in get_function_lines
if line.startswith("}"):
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 22: ordinal not in range(128)
Exit 1
```
We can fix this issue by using the codecs module to open files in unicode mode.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33389Disable routerkeys.c and part of connection_or.c when building without relay ...2020-06-27T13:48:10ZNick MathewsonDisable routerkeys.c and part of connection_or.c when building without relay mode.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33407Make chutney bridge authorities publish bridges in their networkstatus-bridges2020-07-20T16:07:45ZteorMake chutney bridge authorities publish bridges in their networkstatus-bridgesThis issue depends on the tor bridge descriptor upload fix in legacy/trac#33582, or robust reachability self-tests in legacy/trac#33222.
Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem,...This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582, or robust reachability self-tests in legacy/trac#33222.
Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in legacy/trac#33232.
Once bridges upload their descriptors, we can make chutney check the bridge authority's networkstatus-bridges for bridge nicknames (this ticket).
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 or legacy/trac#33582 fixes. So we'll need to check for:
* the next tor 0.4.4-alpha version, or
* an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33409Pre-commit hook does not stash unstaged changes before running code style che...2020-07-29T14:34:18Zrl1987Pre-commit hook does not stash unstaged changes before running code style checkersHow to reproduce:
1) Make some changes to C files and violate whitespace rules.
2) `git add` affected files and try to `git commit`. Pre-commit hook will not allow it and will print the whitespace issues it found.
3) Fix whitespace prob...How to reproduce:
1) Make some changes to C files and violate whitespace rules.
2) `git add` affected files and try to `git commit`. Pre-commit hook will not allow it and will print the whitespace issues it found.
3) Fix whitespace problems, but forget to `git add` the files.
4) Running `git commit` again does not reject the changes, despite whitespace fixes not being staged. New commit now includes whitespace violations and none of the fixes that were done in step 3.
This is not limited to whitespace issues, but could affect other code style checks as well.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33417remove nickname from MyFamily man page section2020-11-04T14:18:22Znusenuremove nickname from MyFamily man page sectionThis is originally from https://trac.torproject.org/projects/tor/ticket/22223#comment:6
but it is still in the man page as of 0.4.2.6
Please remove this phrase from the tor man page
```
When listing a node, it's better to list it ...This is originally from https://trac.torproject.org/projects/tor/ticket/22223#comment:6
but it is still in the man page as of 0.4.2.6
Please remove this phrase from the tor man page
```
When listing a node, it's better to list it by fingerprint than by
nickname: fingerprints are more reliable.
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33427Link to the auto-generated documentation in GettingStarted.md2020-06-27T13:48:08ZteorLink to the auto-generated documentation in GettingStarted.mdOur GettingStarted.md developer document still links to the old torguts git repository:
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/GettingStarted.md#n53
But it should link to our new auto-generated documentation.
I don't kn...Our GettingStarted.md developer document still links to the old torguts git repository:
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/GettingStarted.md#n53
But it should link to our new auto-generated documentation.
I don't know the details of the new docs website. But it would be nice to have it done for Outreachy.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33436Remove all non-dirauth usage of dirauth timing options.2021-09-16T14:22:17ZNick MathewsonRemove all non-dirauth usage of dirauth timing options.There's code in shared_random_client.c that uses dirauth-only options, directly or indirectly. It shouldn't, since clients should only be looking at the consensus to learn what the vote schedule is.There's code in shared_random_client.c that uses dirauth-only options, directly or indirectly. It shouldn't, since clients should only be looking at the consensus to learn what the vote schedule is.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33458Assertion desc failed in hs_client_close_intro_circuits_from_desc at src/feat...2021-06-23T17:22:41ZGeorge KadianakisAssertion desc failed in hs_client_close_intro_circuits_from_desc at src/feature/hs/hs_client.c: 2413Just got this assert failure in my TBB. I had a v3 onion open, and long ago I visited a client-auth onion that I didn't manage to decrypt so it lingered in my cache with `->desc` set to `NULL`.
```
Feb 26 14:17:31.000 [err] tor_asserti...Just got this assert failure in my TBB. I had a v3 onion open, and long ago I visited a client-auth onion that I didn't manage to decrypt so it lingered in my cache with `->desc` set to `NULL`.
```
Feb 26 14:17:31.000 [err] tor_assertion_failed_(): Bug: src/feature/hs/hs_client.c:2413: hs_client_close_intro_circuits_from_desc: Assertion desc failed; aborting. (on T
or 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: Tor 0.4.3.2-alpha (git-dcbf6611d9980953): Assertion desc failed in hs_client_close_intro_circuits_from_desc at src/feature/hs/hs_client.c:
2413: . Stack trace: (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(log_backtrace_impl+0x56) [0x5623c8fe6e96] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_assertion_failed_+0x147) [0x5623c8fe1f97] (on Tor 0.4.3.2-alpha dcbf6611d9980
953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(hs_client_close_intro_circuits_from_desc+0xb6) [0x5623c8ee7c76] (on Tor 0.4.3.2-a
lpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(hs_cache_clean_as_client+0xf2) [0x5623c8edfbd2] (on Tor 0.4.3.2-alpha dcbf6611d99
80953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x6ebbc) [0x5623c8e3fbbc] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x73487) [0x5623c8e44487] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: ./TorBrowser/Tor/libevent-2.1.so.6(+0x22565) [0x7f3c28b8a565] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: ./TorBrowser/Tor/libevent-2.1.so.6(event_base_loop+0x517) [0x7f3c28b8af27] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(do_main_loop+0xdb) [0x5623c8e4372b] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_run_main+0x10b5) [0x5623c8e309f5] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_main+0x3a) [0x5623c8e2e19a] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(main+0x19) [0x5623c8e2dd39] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3c28207bbb] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x5cd89) [0x5623c8e2dd89] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33463Correct spacing in dns_launch_correctness_checks()2020-06-27T13:48:07ZNeel Chauhanneel@neelc.orgCorrect spacing in dns_launch_correctness_checks()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33469INTERNAL ERROR: Raw assertion failed at src/lib/malloc/map_anon.c:239: lock_r...2022-06-17T18:06:22ZTracINTERNAL ERROR: Raw assertion failed at src/lib/malloc/map_anon.c:239: lock_result == 0I tried updating to latest stable version and I have this error after a couple of minutes:
```
Feb 27 14:38:04.987 [notice] Tor 0.4.2.6 (git-971a6beff5a53434) running on Windows Server 2003 with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zli...I tried updating to latest stable version and I have this error after a couple of minutes:
```
Feb 27 14:38:04.987 [notice] Tor 0.4.2.6 (git-971a6beff5a53434) running on Windows Server 2003 with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Feb 27 14:38:05.003 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 27 14:38:05.018 [notice] Read configuration file "U:\2\Server\TOR\tor.ini".
Feb 27 14:38:05.018 [notice] Based on detected system memory, MaxMemInQueues is set to 2048 MB. You can override this by setting MaxMemInQueues by hand.
Feb 27 14:38:05.034 [warn] You specified a public address '0.0.0.0:8080' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
Feb 27 14:38:05.034 [notice] Opening Socks listener on 0.0.0.0:8080
Feb 27 14:38:05.034 [notice] Opened Socks listener on 0.0.0.0:8080
Feb 27 14:38:05.034 [notice] Opening Control listener on 127.0.0.1:9051
Feb 27 14:38:05.049 [notice] Opened Control listener on 127.0.0.1:9051
Feb 27 14:38:05.049 [notice] Opening OR listener on 0.0.0.0:9001
Feb 27 14:38:05.049 [notice] Opened OR listener on 0.0.0.0:9001
Feb 27 14:38:05.049 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 27 14:38:05.049 [notice] Opened Directory listener on 0.0.0.0:9030
============================================================ T= 1582807176
INTERNAL ERROR: Raw assertion failed in Tor 0.4.2.6 (git-971a6beff5a53434) at src/lib/malloc/map_anon.c:239: lock_result == 0
```
**Trac**:
**Username**: m95dhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33491tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal...2022-10-11T23:39:34ZTractor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC ...Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
```
Mar 1 13:53:33 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
```
**Trac**:
**Username**: sjcjonkerTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33511Unknown option 'HiddenServiceOnionBalanceInstance'2020-06-27T13:48:07ZTracUnknown option 'HiddenServiceOnionBalanceInstance'I did git clone master branch which was merged with ticket32709_044_02 already, but I do receive this error when start tor:
```
Tor 0.4.4.0-alpha-dev (git-9892cc3b12db4dc1) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2k-fip...I did git clone master branch which was merged with ticket32709_044_02 already, but I do receive this error when start tor:
```
Tor 0.4.4.0-alpha-dev (git-9892cc3b12db4dc1) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2k-fips, Zlib 1.2.7, Liblzma 5.2.2, and Libzstd N/A.
Mar 03 08:06:55.980 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 03 08:06:55.980 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 03 08:06:55.980 [notice] Read configuration file "/etc/tor/torrc".
Mar 03 08:06:55.982 [warn] Failed to parse/validate config: Unknown option 'HiddenServiceOnionBalanceInstance'. Failing.
**Trac**:
**Username**: roman.kofevarka@gmail.comTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33531surprise newline at the end of info-level cbt log2020-06-27T13:48:06ZRoger Dingledinesurprise newline at the end of info-level cbt logIn circuit_expire_building() there is an info-level log that logs a \n character:
```
log_info(LD_CIRC,
- "Deciding to count the timeout for circuit %"PRIu32"\n",
+ "Deciding to count the timeout...In circuit_expire_building() there is an info-level log that logs a \n character:
```
log_info(LD_CIRC,
- "Deciding to count the timeout for circuit %"PRIu32"\n",
+ "Deciding to count the timeout for circuit %"PRIu32,
TO_ORIGIN_CIRCUIT(victim)->global_identifier);
```
the result is that I get strange blank lines in my log. I see them most obviously when I am doing
```
grep -v "\[info\]" /path/to/log-file|less
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33538v3bw files with too large of weights lead to relays being selected nearly uni...2021-09-27T16:44:52Zpastlyv3bw files with too large of weights lead to relays being selected nearly uniformly at randomAs part of working on the FlashFlow paper (currently under submission) we ran Shadow simulations and compared it to TorFlow. Not surprising.
Summary of the Shadow network used:
- 5% of the real Tor network in size
- 44 exits
- ...As part of working on the FlashFlow paper (currently under submission) we ran Shadow simulations and compared it to TorFlow. Not surprising.
Summary of the Shadow network used:
- 5% of the real Tor network in size
- 44 exits
- 104 guards
- 180 middles
- 3 auths
- 10 "markov" clients. It's not terribly important to know what they're doing, other than knowing they're making lots of 3-hop exit circuits and exchanging traffic with servers. 2 of the clients have tor debug logs. All 10 contribute to the relay selection data.
- Tor version used is a63b4148229ae8ce46494fd6a0f99149c231605c (master branch as of March 5th, 2020) plus a small logging patch. [Branch here](https://github.com/pastly/public-tor/tree/log-relay-weights). This existed in 0.3.5.7 as well. I don't know when this problem started because I don't know exactly what the problem is.
- Shadow 292cd89ba52fc2972fdd9d2e27e384db9601663b (as of Jan 10th, 2020).
- Shadow-plugin-tor 8deab15a032f5173ba7c12ad6dd0bcb1cb0c3463 (as of Oct 2019) plus patch so it works with new Tors. [Branch here](https://github.com/pastly/shadow-plugin-tor/tree/three-stubs).
The only difference in the simulations are the v3bw files used.
There are three simulations:
1. Torflow-derived weights (TF)
1. FlashFlow-derived weights (FF init)
1. FlashFlow-derived weights that have all been divided by 136 (FF scaled)
weight-dist.pdf shows the distribution of the weights in the v3bw files, both with the raw absolute weights and as normalized (norm_weight = weight / total_weight). Despite having nearly identical normalized weight distributions (note: FF init and FF scaled are obviously identical), FF init results in (1) relays being selected seemingly uniformly at random, and (2) significantly worse performance as a consequence.
selection-v-weight.pdf shows how often the 10 markov clients picked each relay. Focus on the scatter plots. Notice how in TF and FF scaled there is basically a 1:1 linear relationship between additional weight and selection frequency, while in FF init the selection frequency is roughly the same regardless of the relay's weight.
I am also attaching the three v3bw files, combined into one file to reduce email spam.
I am also attaching small snippits from the debug logs (again: combined into one file) of one of the markov clients. The snippits show some of the relay weights the client is using when deciding which relays to use. You can see in the FF initial one that the weights are much more similar than in FF scaled and TF.https://gitlab.torproject.org/tpo/core/tor/-/issues/33542Orbot not working after the update.2020-07-29T14:39:26ZTracOrbot not working after the update.Hello,
I have an Android 7.1.1 and after updated the Orbot then it can't work. It just show me "Orbot is starting..." . I removed and installed it again, but problem not solved.
How can I fix it?
Thank you.
**Trac**:
**Username**: Ha...Hello,
I have an Android 7.1.1 and after updated the Orbot then it can't work. It just show me "Orbot is starting..." . I removed and installed it again, but problem not solved.
How can I fix it?
Thank you.
**Trac**:
**Username**: Hack3rconhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33544dir/param_voting_lookup unit-test fails when ALL_BUGS_ARE_FATAL is set2021-09-16T14:22:17Zrl1987dir/param_voting_lookup unit-test fails when ALL_BUGS_ARE_FATAL is setIt crashes with the following stack trace:
```
dir/param_voting_lookup: Mar 06 17:40:13.813 [err] tor_assertion_failed_: Bug: src/feature/dirauth/dirvote.c:898: dirvote_get_intermediate_param_value: Assertion (n_found == 0) failed; abor...It crashes with the following stack trace:
```
dir/param_voting_lookup: Mar 06 17:40:13.813 [err] tor_assertion_failed_: Bug: src/feature/dirauth/dirvote.c:898: dirvote_get_intermediate_param_value: Assertion (n_found == 0) failed; aborting. (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: Tor 0.4.4.0-alpha-dev (git-1da0b05a5cace6ed): Assertion (n_found == 0) failed in dirvote_get_intermediate_param_value at src/feature/dirauth/dirvote.c:898: . Stack trace: (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: 0 test 0x0000000107c0eaec log_backtrace_impl + 60 (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: 1 test 0x0000000107c07adb tor_assertion_failed_ + 699 (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: 2 test 0x00000001079bc70e dirvote_get_intermediate_param_value + 510 (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: 3 test 0x00000001074b17d5 test_dir_param_voting_lookup + 1045 (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: 4 test 0x00000001078ad35a testcase_run_bare_ + 154 (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: 5 test 0x00000001078acee3 testcase_run_one + 355 (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: 6 test 0x00000001078ada7f tinytest_main + 863 (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: 7 test 0x00000001078ac168 main + 1160 (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
Mar 06 17:40:13.813 [err] Bug: 8 libdyld.dylib 0x00007fff6bfc3405 start + 1 (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
make: *** [test] Abort trap: 6
```
Compiled with: `./configure CFLAGS="-DALL_BUGS_ARE_FATAL"`.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33545assertion failure when "all zero" client auth key provided2021-08-23T15:12:44ZMark Smithassertion failure when "all zero" client auth key providedWhile doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:142...While doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:1423: decrypt_descriptor_cookie: Assertion !fast_mem_is_zero((char *) client_auth_sk, sizeof(*client_auth_sk)) failed; aborting. (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
```
As it turns out, I happened to enter a key that is consists entirely of zero bits. This is an unusual thing to do, but I do not think tor should exit.
Steps to reproduce in Tor Browser:
1. Try to load an http or https page for a v3 onion service that requires client authentication, e.g., dgoulet's test server.
2. Enter 56 'A's when prompted for a client auth key.
Result: tor exits due to the assertion failure. Behind the scenes, the browser installs the key via a control port command like the following:
```
onion_client_auth_add <onion-addr> x25519:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
```
and then tries to access the onion service again (page reload).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/33546hs_intropoint/introduce1_validation unit test fails when Tor is built with AL...2021-09-16T14:22:17Zrl1987hs_intropoint/introduce1_validation unit test fails when Tor is built with ALL_BUGS_ARE_FATAL macro```
hs_intropoint/introduce1_validation: [forking] Mar 06 17:21:09.753 [err] tor_assertion_failed_(): Bug: src/feature/hs/hs_intropoint.c:584: validate_introduce1_parsed_cell: Assertion !(!fast_mem_is_zero((char *) legacy_key_id, legacy_...```
hs_intropoint/introduce1_validation: [forking] Mar 06 17:21:09.753 [err] tor_assertion_failed_(): Bug: src/feature/hs/hs_intropoint.c:584: validate_introduce1_parsed_cell: Assertion !(!fast_mem_is_zero((char *) legacy_key_id, legacy_key_id_len)) failed; aborting. (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.758 [err] Bug: Tor 0.4.4.0-alpha-dev (git-4cf24160c28465b7): Assertion !(!fast_mem_is_zero((char *) legacy_key_id, legacy_key_id_len)) failed in validate_introduce1_parsed_cell at src/feature/hs/hs_intropoint.c:584: . Stack trace: (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.758 [err] Bug: ./src/test/test(log_backtrace_impl+0x40) [0x563d777b34cf] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.758 [err] Bug: ./src/test/test(tor_assertion_failed_+0x1cc) [0x563d777ade18] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.758 [err] Bug: ./src/test/test(validate_introduce1_parsed_cell+0xe0) [0x563d775c81af] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.759 [err] Bug: ./src/test/test(+0x40266c) [0x563d771e866c] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.759 [err] Bug: ./src/test/test(+0x69574e) [0x563d7747b74e] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.759 [err] Bug: ./src/test/test(+0x69582c) [0x563d7747b82c] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.759 [err] Bug: ./src/test/test(testcase_run_one+0x133) [0x563d7747bada] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.759 [err] Bug: ./src/test/test(tinytest_main+0x387) [0x563d7747c579] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.760 [err] Bug: ./src/test/test(main+0x40d) [0x563d7747b174] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.760 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7fca3be9eb97] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
Mar 06 17:21:09.760 [err] Bug: ./src/test/test(_start+0x2a) [0x563d76e7087a] (on Tor 0.4.4.0-alpha-dev 4cf24160c28465b7)
[Lost connection!]
[introduce1_validation FAILED]
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33550Bandbreiten Problem mit der Brücke2020-07-29T14:38:54ZTracBandbreiten Problem mit der BrückeHi everyone.
It looks like I can no longer reach the full bandwidth with my relay or my bridge. Are there currently problems in the network or is it due to my server? I released 16Mbits. And it looks like my bridge is not valid.
Sorry, ...Hi everyone.
It looks like I can no longer reach the full bandwidth with my relay or my bridge. Are there currently problems in the network or is it due to my server? I released 16Mbits. And it looks like my bridge is not valid.
Sorry, but I'm an absolute amateur.
This is my bridge:
[https://metrics.torproject.org/rs.html#details/0A2A19DCF7D6C3D07CBDA06AF44A8B90114B8033]
**Trac**:
**Username**: habusTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33553Target and Eliminate http & adjacent algorithms & increase algorithm complexi...2020-07-29T14:38:27ZcypherpunksTarget and Eliminate http & adjacent algorithms & increase algorithm complexity given set standard.Core network of nodes limit to https only by default for clear net interaction.
Eliminate "128" algorithms and weak SSL&TLS
Focus on quantum and PQ encryption of traffic.Core network of nodes limit to https only by default for clear net interaction.
Eliminate "128" algorithms and weak SSL&TLS
Focus on quantum and PQ encryption of traffic.https://gitlab.torproject.org/tpo/core/tor/-/issues/33554Excessive CPU usage in windows tor_cond_t code?2020-07-29T14:37:47ZNick MathewsonExcessive CPU usage in windows tor_cond_t code?On legacy/trac#33411, gvanem reports excdessive CPU consumption in the windows tor_cond_t code. We should see if we can fix that.On legacy/trac#33411, gvanem reports excdessive CPU consumption in the windows tor_cond_t code. We should see if we can fix that.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33555Space out the line.key/line.value in test_policy_summary_helper_family_flags()2020-06-27T13:48:05ZNeel Chauhanneel@neelc.orgSpace out the line.key/line.value in test_policy_summary_helper_family_flags()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33572Add the tor version key to the bandwidth file specification2020-06-27T13:48:05ZjugaAdd the tor version key to the bandwidth file specificationIt has already been done and reviewed in https://trac.torproject.org/projects/tor/ticket/30196#comment:16, but the component of that ticket is sbws, no Tor.
GH PR: https://github.com/torproject/torspec/pull/107.It has already been done and reviewed in https://trac.torproject.org/projects/tor/ticket/30196#comment:16, but the component of that ticket is sbws, no Tor.
GH PR: https://github.com/torproject/torspec/pull/107.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33573Update dir-spec descriptor cosmetic difference criteria (12 hours -> 2 hours)2020-06-27T13:48:05ZoparaUpdate dir-spec descriptor cosmetic difference criteria (12 hours -> 2 hours)In section 3.2 of the dir-spec document it says:
```
If the authority _does_ have a descriptor with the same public key, the
newly uploaded descriptor is remembered if its publication time is more
recent than the most recent old descrip...In section 3.2 of the dir-spec document it says:
```
If the authority _does_ have a descriptor with the same public key, the
newly uploaded descriptor is remembered if its publication time is more
recent than the most recent old descriptor for that router, and either:
- There are non-cosmetic differences between the old descriptor and the
new one.
- Enough time has passed between the descriptors' publication times.
(Currently, 12 hours.)
```
This value of 12 hours was change in [commit cc351578](https://gitweb.torproject.org/tor.git/commit/?id=cc3515780529277a5f9d788e8a256798e5cd144f) to 2 hours.
In addition, [a comment](https://gitweb.torproject.org/tor.git/tree/src/feature/nodelist/routerlist.c?id=8096f3b2549971e120fa3869ea9e458fdad313d5#n2925) in the tor code still says 12 hours.
This ticket covers two changes:
- update the dir-spec to say 2 hours
- update a comment in the tor code
Will attach two PRs shortly.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33607Stop forcing IPv4 and IPv6 traffic on non-SOCKSPorts2021-07-09T17:22:51ZteorStop forcing IPv4 and IPv6 traffic on non-SOCKSPortsAfter legacy/trac#32994, the defaults in `port_cfg_new()` will apply to all parsed ports. (Not just default ports.)
I am not sure what we should do with the extra settings in `connection_listener_new()`:
```
if (type != CONN_TYPE_AP_L...After legacy/trac#32994, the defaults in `port_cfg_new()` will apply to all parsed ports. (Not just default ports.)
I am not sure what we should do with the extra settings in `connection_listener_new()`:
```
if (type != CONN_TYPE_AP_LISTENER) {
lis_conn->entry_cfg.ipv4_traffic = 1;
lis_conn->entry_cfg.ipv6_traffic = 1;
lis_conn->entry_cfg.prefer_ipv6 = 1;
}
```
Here are our options:
* leave them there: non-SOCKSPorts will always have IPv4, IPv6, and prefer IPv6 traffic
* copy the defaults from port_cfg_new(): non-SOCKSPorts will always have DNS, Onion, and prefer IPv6 virtual addresses. Forcing these options on might make some configs break.
* delete them: non-SOCKSPorts can now disable IPv4, IPv6, and prefer IPv4 traffic. Some rare configs might break, because they relied on the options being forced on.
Here's what I think we should do long-term:
* set reasonable defaults (in legacy/trac#32994)
* stop forcing options on (this ticket)
* warn users that some rare configs might break, and they should remove NoIPv4Traffic or NoIPv6Traffic as needed (this changes file)
"prefer IPv6 traffic" was added in legacy/trac#32637 in 0.4.3.1-alpha. We don't want to force that option on in 0.4.3, that makes the problem worse, and might break some existing configs. See legacy/trac#33608 for a fix.https://gitlab.torproject.org/tpo/core/tor/-/issues/33608Stop forcing prefer IPv6 on non-SOCKSPorts2020-06-27T13:48:04ZteorStop forcing prefer IPv6 on non-SOCKSPortsIn legacy/trac#32637 we forced PreferIPv6 on all non-SOCKSPorts.
That could be a breaking change for some users, and they will have no way to recover. We should just set a sensible default, and let users tweak it if it doesn't work for ...In legacy/trac#32637 we forced PreferIPv6 on all non-SOCKSPorts.
That could be a breaking change for some users, and they will have no way to recover. We should just set a sensible default, and let users tweak it if it doesn't work for them.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33616Some errors make Tor's Travis CI exceed the output length limit2020-06-27T13:48:04ZteorSome errors make Tor's Travis CI exceed the output length limitWhen tor has a memory leak, its output can exceed the 10,000 line Travis CI limit:
https://travis-ci.org/github/torproject/tor/builds/662056738
These excess logs may also happen in other cases.
We should work out if we can make some of...When tor has a memory leak, its output can exceed the 10,000 line Travis CI limit:
https://travis-ci.org/github/torproject/tor/builds/662056738
These excess logs may also happen in other cases.
We should work out if we can make some of the output shorter, to work around this issue.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33237Prop 312: 3.2.2. Stop Directory Authorities Resolving *Port Hostnames2021-08-23T15:12:44ZteorProp 312: 3.2.2. Stop Directory Authorities Resolving *Port HostnamesFor security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort an...For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort and DirPort options.
As part of this fix, we may also ban DNS resolution on all configured Ports. (We should try to avoid banning DNS resolution entirely on authorities, because some test networks use Authority/Exits.)
See proposal 312, section 3.2.2, directory authority case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n340
Directory authorities must not attempt to resolve these
addresses using DNS. It is a config error to provide a hostname as a
directory authority's ORPort or DirPort.
If directory authorities don't have an IPv4 address literal in their
Address or ORPort, they should issue a configuration error, and refuse to
launch. If directory authorities don't have an IPv6 address literal in their
Address or ORPort, they should issue a notice-level log, and fall back to
only using IPv4.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33582Make bridges wait until they have bootstrapped, before publishing their descr...2022-06-17T18:47:09ZteorMake bridges wait until they have bootstrapped, before publishing their descriptorInstead of this fix, we can make chutney check tor's logs for reachability self-test successes (legacy/trac#34037), or implement strict self-tests (legacy/trac#33222).
On bridges, there's a race condition when bridges try to publish the...Instead of this fix, we can make chutney check tor's logs for reachability self-test successes (legacy/trac#34037), or implement strict self-tests (legacy/trac#33222).
On bridges, there's a race condition when bridges try to publish their descriptor to the bridge authority:
* bridges try to publish their descriptors before bootstrapping
* but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Bridges will eventually try to publish their descriptors again, when they become dirty.
We should make bridges wait until they have bootstrapped, before they try to publish their descriptors. (This might be a good change for relays as well: there isn't much point in publishing a relay that can't bootstrap.)
This issue happens regardless of `AssumeReachable`. It is most obvious in chutney networks.
This ticket isn't essential. But the workarounds seem to cause weird race conditions, which are time-consuming to diagnose and fix.https://gitlab.torproject.org/tpo/core/tor/-/issues/33619Resolve TROVE-2020-0042020-06-27T13:48:03ZNick MathewsonResolve TROVE-2020-004This is a remotely triggerable memory leak on relays and clients, found by tobias pulls.
The issue is that when circpad_setup_machine_on_circ() is reached with an inconsistent internal configuration, it fails to free an object that is r...This is a remotely triggerable memory leak on relays and clients, found by tobias pulls.
The issue is that when circpad_setup_machine_on_circ() is reached with an inconsistent internal configuration, it fails to free an object that is replaced. It logs a bug warning, but that isn't enough.
Tobias Pulls found that this code was actually reachable, though, and results in a memory leak.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33623sendme: Change default emit cell version from 0 to 12020-07-09T15:03:04ZDavid Gouletdgoulet@torproject.orgsendme: Change default emit cell version from 0 to 1In legacy/trac#32774, the consensus is telling every relay to emit SENDME v1.
We should change the default hardcoded value from 0 to 1 as well.In legacy/trac#32774, the consensus is telling every relay to emit SENDME v1.
We should change the default hardcoded value from 0 to 1 as well.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33639Add CHANNEL_CLOSED reason to specs2020-06-27T13:48:02ZGeorg KoppenAdd CHANNEL_CLOSED reason to specsI was recently looking at stem debug logs and found
```
2020-03-17 21:10:58,838 stem [INFO] CIRC event had an unrecognized remote_reason (CHANNEL_CLOSED). Maybe a new addition to the control protocol? Full Event: 'CIRC 6 FAILED $0CDD60E4...I was recently looking at stem debug logs and found
```
2020-03-17 21:10:58,838 stem [INFO] CIRC event had an unrecognized remote_reason (CHANNEL_CLOSED). Maybe a new addition to the control protocol? Full Event: 'CIRC 6 FAILED $0CDD60E4015EBF2C3B5D32A2B9CC8FE6C98A5C33~UnivUtah3 PURPOSE=GENERAL TIME_CREATED=2020-03-17T20:10:25.388134 REASON=DESTROYED REMOTE_REASON=CHANNEL_CLOSED'
```
I am not sure how the `stem` workflow works but I guess it's an implementation based on the spec(s) (not what is actually used/allowed in the tor code).
Thus, we should fix the spec(s) first so we can add the respective `stem` part later on.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33640Add PATH_BIAS_TESTING purpose to specs2020-06-27T13:48:02ZGeorg KoppenAdd PATH_BIAS_TESTING purpose to specsSimilar to legacy/trac#33639 I found
```
2020-03-17 21:26:35,977 stem [INFO] CIRC event had an unrecognized purpose (PATH_BIAS_TESTING). Maybe a new addition to the control protocol? Full Event: 'CIRC 322 CLOSED $8E915C44FD55A433CCAFACF4...Similar to legacy/trac#33639 I found
```
2020-03-17 21:26:35,977 stem [INFO] CIRC event had an unrecognized purpose (PATH_BIAS_TESTING). Maybe a new addition to the control protocol? Full Event: 'CIRC 322 CLOSED $8E915C44FD55A433CCAFACF4902BF1B2B16DD36C~snap277,$ECE90C4159D916921F7C8DDF4D088AC3808C521D~piss PURPOSE=PATH_BIAS_TESTING TIME_CREATED=2020-03-17T20:26:15.358481 REASON=FINISHED'
```
in my `stem` logs and it seems `PATH_BIAS_TESTING` needs to get added to the specs as a "new" `PURPOSE` so `stem` can pick this up, too.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33641Spurious coverity unreachable warning after all bugs are fatal test skip2020-06-27T13:48:02ZteorSpurious coverity unreachable warning after all bugs are fatal test skipThere's a spurious coverity warning about unreachable code, in tests that we're skipping when ALL_BUGS_ARE_FATAL is defined.
I guess we need to wrap those skips in `#ifndef COVERITY`.
```
** CID 1460753: Control flow issues (UNREACHA...There's a spurious coverity warning about unreachable code, in tests that we're skipping when ALL_BUGS_ARE_FATAL is defined.
I guess we need to wrap those skips in `#ifndef COVERITY`.
```
** CID 1460753: Control flow issues (UNREACHABLE)
/src/test/test_dir.c: 4998 in test_dir_purpose_needs_anonymity_returns_true_by_default()
________________________________________________________________________________________________________
*** CID 1460753: Control flow issues (UNREACHABLE)
/src/test/test_dir.c: 4998 in test_dir_purpose_needs_anonymity_returns_true_by_default()
4992 (void)arg;
4993
4994 #ifdef ALL_BUGS_ARE_FATAL
4995 tt_skip();
4996 #endif
4997
CID 1460753: Control flow issues (UNREACHABLE)
This code cannot be reached: "tor_capture_bugs_(1);".
4998 tor_capture_bugs_(1);
4999 setup_full_capture_of_logs(LOG_WARN);
5000 tt_int_op(1, OP_EQ, purpose_needs_anonymity(0, 0, NULL));
5001 tt_int_op(1, OP_EQ, smartlist_len(tor_get_captured_bug_log_()));
5002 expect_single_log_msg_containing("Called with dir_purpose=0");
5003
** CID 1460752: Control flow issues (UNREACHABLE)
/src/test/test_circuitbuild.c: 123 in test_new_route_len_unhandled_exit()
________________________________________________________________________________________________________
*** CID 1460752: Control flow issues (UNREACHABLE)
/src/test/test_circuitbuild.c: 123 in test_new_route_len_unhandled_exit()
117 #ifdef ALL_BUGS_ARE_FATAL
118 tt_skip();
119 #endif
120
121 MOCK(count_acceptable_nodes, mock_count_acceptable_nodes);
122
CID 1460752: Control flow issues (UNREACHABLE)
This code cannot be reached: "tor_capture_bugs_(1);".
123 tor_capture_bugs_(1);
124 setup_full_capture_of_logs(LOG_WARN);
125 r = new_route_len(CIRCUIT_PURPOSE_CONTROLLER, &dummy_ei, &dummy_nodes);
126 tt_int_op(DEFAULT_ROUTE_LEN + 1, OP_EQ, r);
127 tt_int_op(smartlist_len(tor_get_captured_bug_log_()), OP_EQ, 1);
128 tt_str_op(smartlist_get(tor_get_captured_bug_log_(), 0), OP_EQ,
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33642Add *.a to .gitignore2020-06-27T13:48:02ZDavid Gouletdgoulet@torproject.orgAdd *.a to .gitignoreMade a mistake to add a .a file while switching from 043 and master into a branch.
I think adding `*.a` to .gitignore should be a reasonable idea since these files are always generated in our build system.Made a mistake to add a .a file while switching from 043 and master into a branch.
I think adding `*.a` to .gitignore should be a reasonable idea since these files are always generated in our build system.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33643Appveyor: OpenSSL version mismatch in unit tests, 2020 edition2020-06-27T13:48:02ZteorAppveyor: OpenSSL version mismatch in unit tests, 2020 editionIt's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like legacy/trac#32449, legacy/trac#285...It's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like legacy/trac#32449, legacy/trac#28574, legacy/trac#28399 and legacy/trac#25942.
We think our tests are fragile, because they are not copying the necessary libraries into `${env:build}/src/test` from `C:/mingw32/lib`:
```
ssl
crypto
lzma
event
zstd
```
We already copy zlib and ssp at https://github.com/ahf/tor/blob/master/.appveyor.yml#L98-L99 .
These libraries might have different dll prefixes or suffixes, for example, OpenSSL is:
```
/mingw32/bin/libcrypto-1_1.dll
/mingw32/bin/libssl-1_1.dll
```
https://packages.msys2.org/package/mingw-w64-i686-openssl
We might also want to copy these libraries into the same directory as the tor executable `${env:build}/src/app`, before we run the tests that launch tor.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33646Wrong list of enabled modules2021-07-05T11:27:26ZTracWrong list of enabled modulesWhen I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth...When I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth (--disable-module-dirauth): yes
dircache (--disable-module-dircache): yes
```
Which is wrong, since I have enabled relay and disabled dirauth.
Looks like problem is located in commit [9c33d36113447d38decd22d177e62fb225826d78](https://gitweb.torproject.org/tor.git/commit/?id=9c33d36113447d38decd22d177e62fb225826d78).
Related: legacy/trac#32230.
Please recheck.
**Trac**:
**Username**: VortTor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33651Suspicious "fetched this many bytes" counts from #327202020-06-27T13:48:01ZRoger DingledineSuspicious "fetched this many bytes" counts from #32720Following legacy/trac#32720, now I have these log messages in my Tor client:
```
Mar 17 17:52:52.004 [notice] Bootstrapped 100% (done): Done
Mar 17 23:52:49.170 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've s...Following legacy/trac#32720, now I have these log messages in my Tor client:
```
Mar 17 17:52:52.004 [notice] Bootstrapped 100% (done): Done
Mar 17 23:52:49.170 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 166.22 MB and received 5.25 GB.
Mar 17 23:52:49.178 [notice] While bootstrapping, fetched this many bytes:
Mar 17 23:52:49.178 [notice] 542559 (consensus network-status fetch)
Mar 17 23:52:49.178 [notice] While not bootstrapping, fetched this many bytes:
Mar 17 23:52:49.178 [notice] 542559 (consensus network-status fetch)
Mar 17 23:52:49.178 [notice] Average packaged cell fullness: 52.843%. TLS write overhead: 3%
Mar 18 17:01:52.177 [notice] Your system clock just jumped 44387 seconds forward; assuming established circuits no longer work.
Mar 18 18:12:33.010 [notice] Heartbeat: Tor's uptime is 11:59 hours, with 0 circuits open. I've sent 166.25 MB and received 5.25 GB.
Mar 18 18:12:33.011 [notice] While bootstrapping, fetched this many bytes:
Mar 18 18:12:33.011 [notice] 542559 (consensus network-status fetch)
Mar 18 18:12:33.011 [notice] While not bootstrapping, fetched this many bytes:
Mar 18 18:12:33.011 [notice] 542559 (consensus network-status fetch)
Mar 18 18:12:33.011 [notice] Average packaged cell fullness: 52.898%. TLS write overhead: 3%
Mar 19 00:12:33.013 [notice] Heartbeat: Tor's uptime is 17:59 hours, with 0 circuits open. I've sent 166.26 MB and received 5.25 GB.
Mar 19 00:12:33.013 [notice] While bootstrapping, fetched this many bytes:
Mar 19 00:12:33.013 [notice] 542559 (consensus network-status fetch)
Mar 19 00:12:33.013 [notice] While not bootstrapping, fetched this many bytes:
Mar 19 00:12:33.013 [notice] 542559 (consensus network-status fetch)
Mar 19 00:12:33.013 [notice] Average packaged cell fullness: 52.953%. TLS write overhead: 3%
```
I'm running
```
Tor 0.4.4.0-alpha-dev (git-d4595b344a1a3254) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
```
It is surprising to me that I have the same number while bootstrapping and while not bootstrapping, and that number doesn't seem to go up.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33668--disable-module-relay yields to a Bug:2020-06-27T13:48:01Ztoralf--disable-module-relay yields to a Bug:At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and L...At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
Mar 19 19:44:35.840 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 19 19:44:35.840 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 19 19:44:35.840 [notice] Read configuration file "/etc/tor/torrc".
Mar 19 19:44:35.843 [err] tor_assertion_failed_(): Bug: src/app/config/config.c:1473: options_switch_id: Assertion have_low_ports != -1 failed; aborting. (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.844 [err] Bug: Tor 0.4.3.3-alpha: Assertion have_low_ports != -1 failed in options_switch_id at src/app/config/config.c:1473: . Stack trace: (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(log_backtrace_impl+0x59) [0x5564677d3ab9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_assertion_failed_+0x150) [0x5564677cecb0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(set_options+0x404) [0x5564677535d4] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(+0x1648a0) [0x5564677548a0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_string+0x119) [0x556467754af9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_torrc+0x359) [0x5564677550f9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_init+0x1c7) [0x55646764ade7] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_run_main+0x71) [0x55646764b4e1] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_main+0x46) [0x55646764a006] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(main+0x19) [0x556467649bd9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7ff9817b8f1b] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(_start+0x2a) [0x556467649c2a] (on Tor 0.4.3.3-alpha )
Aborted
```
The same tarball at the same system works fine with that option being enabled.
The config is
```
cat /etc/tor/torrc
User tor
PIDFile /var/run/tor/tor.pid
Log notice file /tmp/notice.log
DataDirectory /var/lib/tor/data
CookieAuthentication 1
ControlPort 9051
SocksPort 9050
SandBox 1
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33670Fix erroneous spaces in circuitmux_ewma.c2020-06-27T13:48:01ZNeel Chauhanneel@neelc.orgFix erroneous spaces in circuitmux_ewma.cNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33686Tor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabled2020-06-27T13:48:00ZcypherpunksTor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabledI get this output from the terminal only when Sandbox 1 is enabled and it did not happen on earlier versions:
Mar 21 21:07:21.000 [notice] Bootstrapped 0% (starting): Starting
Mar 21 21:10:10.000 [notice] Starting with guard context "...I get this output from the terminal only when Sandbox 1 is enabled and it did not happen on earlier versions:
Mar 21 21:07:21.000 [notice] Bootstrapped 0% (starting): Starting
Mar 21 21:10:10.000 [notice] Starting with guard context "default"
Mar 21 21:10:10.000 [warn] tor_bug_occurred_(): Bug: src/lib/evloop/workqueue.c:353: workerthread_new: This line should not have been reached. (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: Tor 0.4.2.7: Line unexpectedly reached at workerthread_new at src/lib/evloop/workqueue.c:353. Stack trace: (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(log_backtrace_impl+0x47) [0x600404] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_bug_occurred_+0xa9) [0x5fcea2] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(threadpool_new+0x12b) [0x5ae6b0] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(cpu_init+0x59) [0x4be66e] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(run_tor_main_loop+0x9f) [0x4b3064] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_run_main+0xb85) [0x4b3f16] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_main+0x23) [0x4b1f98] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(main+0x13) [0x4b1c24] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97) [0xb694b524] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [err] Can't launch worker thread.
Mar 21 21:10:10.000 [warn] tor_bug_occurred_(): Bug: src/lib/evloop/workqueue.c:519: threadpool_start_threads: This line should not have been reached. (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: Tor 0.4.2.7: Line unexpectedly reached at threadpool_start_threads at src/lib/evloop/workqueue.c:519. Stack trace: (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(log_backtrace_impl+0x47) [0x600404] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_bug_occurred_+0xa9) [0x5fcea2] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(threadpool_new+0x15b) [0x5ae6e0] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(cpu_init+0x59) [0x4be66e] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(run_tor_main_loop+0x9f) [0x4b3064] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_run_main+0xb85) [0x4b3f16] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_main+0x23) [0x4b1f98] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(main+0x13) [0x4b1c24] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97) [0xb694b524] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] tor_bug_occurred_(): Bug: src/lib/evloop/workqueue.c:563: threadpool_new: This line should not have been reached. (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: Tor 0.4.2.7: Line unexpectedly reached at threadpool_new at src/lib/evloop/workqueue.c:563. Stack trace: (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(log_backtrace_impl+0x47) [0x600404] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_bug_occurred_+0xa9) [0x5fcea2] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(threadpool_new+0x183) [0x5ae708] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(cpu_init+0x59) [0x4be66e] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(run_tor_main_loop+0x9f) [0x4b3064] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_run_main+0xb85) [0x4b3f16] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(tor_main+0x23) [0x4b1f98] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: tor(main+0x13) [0x4b1c24] (on Tor 0.4.2.7 )
Mar 21 21:10:10.000 [warn] Bug: /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97) [0xb694b524] (on Tor 0.4.2.7 )
============================================================ T= 1584825010
Tor 0.4.2.7 died: Caught signal 11
tor(+0x19631a)[0x60031a]
tor(threadpool_register_reply_event+0x19)[0x5ae80e]
tor(threadpool_register_reply_event+0x19)[0x5ae80e]
tor(cpu_init+0x61)[0x4be676]
tor(run_tor_main_loop+0x9f)[0x4b3064]
tor(tor_run_main+0xb85)[0x4b3f16]
tor(tor_main+0x23)[0x4b1f98]
tor(main+0x13)[0x4b1c24]
/lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x97)[0xb694b524]
[1]+ Illegal instruction tor -f torrcTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33687Create rotating DNS DoH/DoT server list option Trr Core Tor2020-07-29T14:43:15ZcypherpunksCreate rotating DNS DoH/DoT server list option Trr Core TorReference
https://github.com/curl/curl/wiki/DNS-over-HTTPS
https://dnsprivacy.org/wiki/m/mobile.action#page/1277971
Add options to UX/UI and etc.Reference
https://github.com/curl/curl/wiki/DNS-over-HTTPS
https://dnsprivacy.org/wiki/m/mobile.action#page/1277971
Add options to UX/UI and etc.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33702RSA_get0_d could not be located in the dynamic link library tor.exe2023-05-31T18:44:10ZTracRSA_get0_d could not be located in the dynamic link library tor.exeOS: Win10 (win64)
Tor Browser will not run, when attempting to establish a connection the following error appeats:
The procedure entry point RSA_get0_d could not be located in the dynamic link library C:\Users\MyUser\Desktop\Tor Browse...OS: Win10 (win64)
Tor Browser will not run, when attempting to establish a connection the following error appeats:
The procedure entry point RSA_get0_d could not be located in the dynamic link library C:\Users\MyUser\Desktop\Tor Browser\Browser\TorBrowser\Tor\tor.exe
**Trac**:
**Username**: ner0https://gitlab.torproject.org/tpo/core/tor/-/issues/33703Improving HS availability under DoS (master ticket)2022-10-11T23:39:34ZGeorge KadianakisImproving HS availability under DoS (master ticket)This is the master ticket for organizing work under this topic.This is the master ticket for organizing work under this topic.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33759recent_measurements_excluded_few_count is used twice in bandwidth spec2020-06-27T13:47:58ZGeorg Koppenrecent_measurements_excluded_few_count is used twice in bandwidth specWhile going over the spec again during review for legacy/trac#30905 I stumbled over `recent_measurements_excluded_few_count` being used twice. The second instance should be `relay_recent_measurements_excluded_few_count` instead.While going over the spec again during review for legacy/trac#30905 I stumbled over `recent_measurements_excluded_few_count` being used twice. The second instance should be `relay_recent_measurements_excluded_few_count` instead.Tor: 0.4.4.x-finalGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33762OnionService v3 running as onionbalance backend fails to reload failing with ...2021-06-23T17:22:41Zs7rOnionService v3 running as onionbalance backend fails to reload failing with get_subcredential_for_handling_intro2_cell: Non-fatal assertion !(!service->ob_subcreds) failed.When you do a **reload** on a Tor process that is running an onion service v3 as an onionbalance backend instance (with `HiddenServiceOnionBalanceInstance 1` in torrc), it fails to come up, making the backend onion service **unavailable*...When you do a **reload** on a Tor process that is running an onion service v3 as an onionbalance backend instance (with `HiddenServiceOnionBalanceInstance 1` in torrc), it fails to come up, making the backend onion service **unavailable** while not exiting the Tor process entirely. The only thing that makes it heal is a _restart_' of the process.
It can be triggered any time you **reload** (SIGHUP) a Tor process with an onion service running with `HiddenServiceOnionBalanceInstance 1`. This is Tor 0.4.4.0-alpha-dev-20200327T132009Z-1~d10.buster+1 from deb.tpo nightly master.
Here is the full stack trace:
```
Mar 29 15:59:12.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Mar 29 15:59:12.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Mar 29 15:59:12.000 [notice] Read configuration file "/etc/tor/torrc".
Mar 29 15:59:12.000 [info] config_generic_service(): HiddenServiceDir="/var/lib/tor/ob-hs". Configuring...
Mar 29 15:59:12.000 [info] config_generic_service(): HiddenServicePort=80 127.0.0.1:80 for "/var/lib/tor/ob-hs"
Mar 29 15:59:12.000 [info] tor_getpwnam(): Caching new entry debian-tor for debian-tor
Mar 29 15:59:12.000 [info] helper_parse_uint64(): HiddenServiceOnionBalanceInstance was parsed to 1
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
Mar 29 15:59:12.000 [notice] Tor 0.4.4.0-alpha-dev opening log file.
Mar 29 16:00:42.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_circuit.c:987: get_subcredential_for_handling_intro2_cell: Non-fatal assertion !(!service->ob_subcreds) failed. (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(!service->ob_subcreds) failed in get_subcredential_for_handling_intro2_cell at ../src/feature/hs/hs_circuit.c:987. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x56) [0x558eb518fee6] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x16c) [0x558eb518b0ec] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(hs_circ_handle_introduce2+0x5eb) [0x558eb5091e3b] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(hs_service_receive_introduce2+0xc3) [0x558eb50a53d3] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x1be) [0x558eb50e672e] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(+0xbe368) [0x558eb502e368] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(+0xbf1c5) [0x558eb502f1c5] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x2b4) [0x558eb5030a44] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x2c8) [0x558eb5013788] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x4eb) [0x558eb4ff2f0b] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(+0xac5ca) [0x558eb501c5ca] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0xa92) [0x558eb4fe03a2] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(+0x75609) [0x558eb4fe5609] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f34833269ba] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f3483327537] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xff) [0x558eb4fe688f] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x10b5) [0x558eb4fd3bc5] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x558eb4fd12ca] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x558eb4fd0e89] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3482c0809b] (on Tor 0.4.4.0-alpha-dev )
Mar 29 16:00:42.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x558eb4fd0eda] (on Tor 0.4.4.0-alpha-dev )
```
One instance has 26 such stack traces across a time period of 6 mins and 54 seconds and the other one 32 such stack traces across a time period of 4 mins and 28 seconds.
----
While we are at this, `config_generic_service()` , `tor_getpwnam()`, `helper_parse_uint64()` and `ob_option_parse()` report **[info]** level logs in a **Log notice file** configured Tor instance, is this normal?Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33767consider using a GitHub mirror for tor-rust-dependencies2021-02-05T21:09:48ZTaylor Yuconsider using a GitHub mirror for tor-rust-dependenciesDuring a recent IP address change of the host of git.torproject.org (legacy/trac#33730), a few Travis CI builds errored due to the unreachability of that host. (I think there were around five errored pull request builds? I restarted abou...During a recent IP address change of the host of git.torproject.org (legacy/trac#33730), a few Travis CI builds errored due to the unreachability of that host. (I think there were around five errored pull request builds? I restarted about three of them, ignoring the builds that were obsolete due to more recent changes.) I think this has happened before due to transient network faults.
We should consider making a GitHub mirror of the tor-rust-dependencies repository, and use that instead of the more canonical git.torproject.org location during Travis builds. (I'm guessing that the github.com repositories are very likely reachable if a Travis build starts successfully.) We might lose the ability to use the default git submodule setup done by Travis, though.
```
$ git submodule update --init --recursive
Submodule 'src/ext/rust' (https://git.torproject.org/tor-rust-dependencies) registered for path 'src/ext/rust'
Cloning into '/home/travis/build/torproject/tor/src/ext/rust'...
fatal: unable to access 'https://git.torproject.org/tor-rust-dependencies/': Failed to connect to git.torproject.org port 443: No route to host
fatal: clone of 'https://git.torproject.org/tor-rust-dependencies' into submodule path '/home/travis/build/torproject/tor/src/ext/rust' failed
Failed to clone 'src/ext/rust'. Retry scheduled
Cloning into '/home/travis/build/torproject/tor/src/ext/rust'...
fatal: unable to access 'https://git.torproject.org/tor-rust-dependencies/': Failed to connect to git.torproject.org port 443: No route to host
fatal: clone of 'https://git.torproject.org/tor-rust-dependencies' into submodule path '/home/travis/build/torproject/tor/src/ext/rust' failed
Failed to clone 'src/ext/rust' a second time, aborting
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33778TestingTorNetwork options in the man page are out of date2021-07-22T16:18:20ZoparaTestingTorNetwork options in the man page are out of dateA few of the values under `TestingTorNetwork` in `doc/tor.1.txt` are out of date compared to the options in `src/app/config/testnet.inc`. Also, some of the units listed for options only state 'minutes|hours' when they actually support 's...A few of the values under `TestingTorNetwork` in `doc/tor.1.txt` are out of date compared to the options in `src/app/config/testnet.inc`. Also, some of the units listed for options only state 'minutes|hours' when they actually support 'seconds' as well. I only fixed the ones that were relevant to `TestingTorNetwork`, but there are probably others as well. Will add a PR shortly.
In addition, many of the options that are of type `INTERVAL` use different units in the man page. For example:
```
ShutdownWaitLength NUM
V3AuthVotingInterval N minutes|hours
TestingV3AuthVotingStartOffset N seconds|minutes|hours
DormantClientTimeout N minutes|hours|days|weeks
```
Since these are all of type `INTERVAL`, is there a reason why these units are different when all of them support any unit in `unitparse.c` (seconds, minutes, hours, days, weeks)? One reason could be that some options have lower bounds (for example `V3AuthVotingInterval` must be greater than 300 seconds which is of the order of minutes), but the user can just specify 300 seconds rather than 5 minutes.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33779Fix incorrect PublishHidServDescriptors value in logs2021-06-23T17:22:41ZteorFix incorrect PublishHidServDescriptors value in logsThis code should say:
"PublishHidServDescriptors is set to 0."
But it says:
```
/* Let's avoid doing that if tor is configured to not publish. */
if (!get_options()->PublishHidServDescriptors) {
log_info(LD_REND, "Service %s not...This code should say:
"PublishHidServDescriptors is set to 0."
But it says:
```
/* Let's avoid doing that if tor is configured to not publish. */
if (!get_options()->PublishHidServDescriptors) {
log_info(LD_REND, "Service %s not publishing descriptor. "
"PublishHidServDescriptors is set to 1.",
safe_str_client(service->onion_address));
goto end;
}
```
I'll leave it to dgoulet and asn to fix, and decide how far it needs to be backported.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33780hs-v3: Change to log notice the registration of an OB instance2021-06-23T17:22:41ZDavid Gouletdgoulet@torproject.orghs-v3: Change to log notice the registration of an OB instanceChange this info to notice:
```
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
```Change this info to notice:
```
Mar 29 15:59:12.000 [info] ob_option_parse(): OnionBalance: MasterOnionAddress *******.onion registered
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33782Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions2020-06-27T13:47:57ZTracIncreases TEST_CONN_FD_INIT to make tests working on GitHub ActionsWith the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_soc...With the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_socket__real: Non-fatal assertion n_sockets_open >= 0 failed. (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: Tor 0.4.2.5: Non-fatal assertion n_sockets_open >= 0 failed in tor_close_socket__real at src/lib/net/socket.c:237. Stack trace: (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(log_backtrace_impl+0x56) [0x55d2831c7696] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_bug_occurred_+0x17f) [0x55d2831c2fcf] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_close_socket__real+0xd7) [0x55d2831ba3f7] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(connection_free_minimal+0x1c7) [0x55d28302a507] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x2d5dff) [0x55d282e91dff] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x444c66) [0x55d283000c66] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(testcase_run_one+0x2f1) [0x55d283000fb1] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tinytest_main+0x10c) [0x55d28300156c] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(main+0x2a0) [0x55d282cad9f0] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f65fdf83b97] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(_start+0x2a) [0x55d282cadb1a] (on Tor 0.4.2.5 )
[e2e_rend_circuit_setup_legacy FAILED]
```
The reason is because of a process running in GitHub Actions doing something that caused a lot of file descriptors to open. So, when Tor is trying to close a fake socket it ends up closing a real one that was opened by GitHub Actions.
I already tried with 100 and it does not work. So I tried 200 and it works.
**Trac**:
**Username**: ultimaweaponTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33788Check the return value of tor_inet_ntop() and tor_inet_ntoa()2021-08-23T15:12:44ZteorCheck the return value of tor_inet_ntop() and tor_inet_ntoa()The following functions don't check the return value of tor_inet_ntop() or tor_inet_ntoa():
IPv6, could be serious:
* evdns_callback(), multiple times
IPv4 only, unlikely to be a serious bug:
* tor_dup_ip()
* fmt_addr32()
* evdns_wildc...The following functions don't check the return value of tor_inet_ntop() or tor_inet_ntoa():
IPv6, could be serious:
* evdns_callback(), multiple times
IPv4 only, unlikely to be a serious bug:
* tor_dup_ip()
* fmt_addr32()
* evdns_wildcard_check_callback()
These functions should log a bug log using BUG() or tor_assert_nonfatal(), and return an error. (Or for the formatting functions, a sensible placeholder string.)
We will also need to make their callers check for the error.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33794hs-v3: OnionBalance backend instances all fail after more introductions by hi...2021-06-23T17:22:42Zs7rhs-v3: OnionBalance backend instances all fail after more introductions by hitting descriptor upload time limitsWe fixed legacy/trac#33762 and thought that was the problem (which it also was) but after fixing that I have discovered that all onionbalance backend instances continue to die after testing and testing (establishing successful RP circuit...We fixed legacy/trac#33762 and thought that was the problem (which it also was) but after fixing that I have discovered that all onionbalance backend instances continue to die after testing and testing (establishing successful RP circuits with the frontend) and never heal unless Tor processes of the backends are restarted.
I was instructed by asn on IRC to look between the time of SIGHUP (logrotate log file change) and time of:
```
[warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_circuit.c:987: get_subcredential_for_handling_intro2_cell: Non-fatal assertion !(!service->ob_subcreds) failed. (on Tor 0.4.4.0-alpha-dev )
```
for the message
```
log_info(LD_REND, "Hidden service %s next descriptor successfully "
"built. Now scheduled for upload.",
```
Which meant that it eventually recovered by itself. I can see two of those messages in ~24 hours, but the backend instances continue to be unavailable. Frontend does not work, and even if you try to connect to the backend address directly instead of the frontend one it does not work.
It looks like it is never able to upload further descriptors at some point, flooding the log file with:
```
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585748071. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585748071. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585748671. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585748671. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585749271. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585749271. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its current descriptor: Next upload time is 1585751537, it is now 1585749871. [598 similar message(s) suppressed in last 600 seconds]
[info] log_cant_upload_desc(): Service [scrubbed] can't upload its next descriptor: Next upload time is 1585751987, it is now 1585749871. [598 similar message(s) suppressed in last 600 seconds]
```
I have info log level files from 2 backend instances of like ~47 MB each.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33804Defer "PreferIPv6 by default" to 0.4.42020-06-27T13:47:56ZteorDefer "PreferIPv6 by default" to 0.4.4In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement ...In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-only resolves for torsocks.
Since legacy/trac#32637, we have also merged:
* legacy/trac#33608, which removes a forced PreferIPv6 for non-SOCKSPorts
* legacy/trac#32994, which puts the PreferIPv6 default in port_parse_config(), rather than in 2 different places in the code
So it should be very easy to change the default for PreferIPv6.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33837Tor.framework Unknown type name 'dispatch_queue_t'2020-06-27T13:47:55ZteorTor.framework Unknown type name 'dispatch_queue_t'From https://trac.torproject.org/projects/tor/ticket/33522#comment:2
>
> Replying to [tla](legacy/trac#33522):
> > It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
> >
> > https://github.c...From https://trac.torproject.org/projects/tor/ticket/33522#comment:2
>
> Replying to [tla](legacy/trac#33522):
> > It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
> >
> > https://github.com/iCepa/Tor.framework/blob/master/.travis.yml
> >
> >
> > Currently, we have issues in getting past Tor 0.4.0.6 on iOS. When I try to use a newer core, I get this error message:
> >
> > > Unknown type name 'dispatch_queue_t'
> >
> > in CFStream of Apple's CoreFoundation framework.
> >
> >
> > But "dispatch_queue_t" is actually a valid symbol from Apple's Foundation libraries.
> >
> > So somehow, it gets cancelled out through something which changed in Tor recently.
>
> This looks like a bug in tor's code, or perhaps in the Tor.framework embedding scripts.
>
> We'd be happy to help you diagnose this issue.
>
> Can you tell us the first release that has this issue? Is it 0.4.1, 0.4.2, or 0.4.3 ?
> Have you done a git bisect, to track down the commit that introduced the issue?
>
> Let's open a separate ticket, so we can fix this bug in tor's code.
> Or help you find a workaround when you embed tor.
I can't see dispatch_queue_t in Tor's code.
Perhaps we're defining some preprocessor symbols, or including a header that conflicts with dispatch_queue_t's header.
We don't know which release this bug was introduced in. But Tor 0.4.0.6 does not have this error.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33839Correct 'was not internal' to 'was internal' in test_external_ip()2020-06-27T13:47:55ZTracCorrect 'was not internal' to 'was internal' in test_external_ip()source: https://github.com/torproject/tor/pull/1856
Fixing a typo in a string that is printed on event of a test failing, in `src/test/test_addr.c`.
**Trac**:
**Username**: kimimarosource: https://github.com/torproject/tor/pull/1856
Fixing a typo in a string that is printed on event of a test failing, in `src/test/test_addr.c`.
**Trac**:
**Username**: kimimaroTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33843Write detailed priority queue scheduler design on the proposal2022-10-11T23:39:34ZGeorge KadianakisWrite detailed priority queue scheduler design on the proposalTor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33850log rotation for /var/log/tor/debug.log did not close handle to old file afte...2020-10-29T15:21:31ZTraclog rotation for /var/log/tor/debug.log did not close handle to old file after compressionso / ran full after a week or so. I found the culprits with:
find /proc/*/fd -ls | grep '(deleted)'
Version: tor 0.4.2.7-1~d8.jessie+1
Config:
Standard torrc with one Hidden service, using an HTTPSProxy and notice+debug logging enabl...so / ran full after a week or so. I found the culprits with:
find /proc/*/fd -ls | grep '(deleted)'
Version: tor 0.4.2.7-1~d8.jessie+1
Config:
Standard torrc with one Hidden service, using an HTTPSProxy and notice+debug logging enabled:
Log notice file /var/log/tor/notices.log
Log debug file /var/log/tor/debug.log
**Trac**:
**Username**: MaKoTorTor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33870vanguards: Vanguards silently fail on certain condition2020-07-30T18:47:31Zcypherpunksvanguards: Vanguards silently fail on certain condition1. Configure torrc file (add some HiddenService lines)
2. Edit vanguards.conf like below:
```
# IP address that the Tor control port is listening on:
control_ip =
# TCP port the control port is listening on:
control_port =
# If set,...1. Configure torrc file (add some HiddenService lines)
2. Edit vanguards.conf like below:
```
# IP address that the Tor control port is listening on:
control_ip =
# TCP port the control port is listening on:
control_port =
# If set, use this filesystem control socket instead of IP+Port:
control_socket = /run/tor/control
# If set, use this as the control port password:
control_pass =
```
```
# The current loglevel:
loglevel = NOTICE
# If specified, log to this file instead of stdout:
logfile = /tmp/vandebugger
```
3. Restart vanguards (service vanguards stop;service vanguards start)
4. Run 'ps axu|grep pypy' - you'll find vanguards is running
5. Now wait 1 minute
---
What will happen:
1. Vanguards silently exit itself. /tmp/vandebugger logged nothing.
2. However if you read syslog you'll find this line:
```
Specified config file /meow/vanguards.conf can't be read: invalid literal for int() with base 10: ''
```
How to fix:
Setting 'control_port = ' to 'control_port = 9876' fixed this.
What do I want:
Error should not be raised if the user set 'control_port' empty string.
#NoGithub #ILikeYourAddonMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33883Fix typo in router_build_fresh_unsigned_routerinfo() comment2020-06-27T13:47:53ZNeel Chauhanneel@neelc.orgFix typo in router_build_fresh_unsigned_routerinfo() commentThis comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```This comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33899Allow IPv6 addresses to be canonical2020-06-27T13:47:53ZteorAllow IPv6 addresses to be canonicalIn legacy/trac#17604, we allowed IPv6 connections to set is_canonical_to_peer. But we did not let them set is_canonical.
So channel_tls_process_netinfo_cell() handles IPv6 addresses, but connection_or_check_canonicity() does not.
This ...In legacy/trac#17604, we allowed IPv6 connections to set is_canonical_to_peer. But we did not let them set is_canonical.
So channel_tls_process_netinfo_cell() handles IPv6 addresses, but connection_or_check_canonicity() does not.
This inconsistency could be one cause of the logging issues in legacy/trac#24841.
We should allow IPv6 connections to be canonical. We should also do some cleanup of the related connection address logging in legacy/trac#33898.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33900Check for invalid zero IPv4 addresses and ports in extend cells2021-09-16T14:21:51ZteorCheck for invalid zero IPv4 addresses and ports in extend cellsWhen we send and parse extend cells, we check that their IPv4 address field is not AF_UNSPEC.
But we should also check for zero IPv4 addresses and zero ports. (Which are both invalid.)
Code and points in legacy/trac#33817, I just neede...When we send and parse extend cells, we check that their IPv4 address field is not AF_UNSPEC.
But we should also check for zero IPv4 addresses and zero ports. (Which are both invalid.)
Code and points in legacy/trac#33817, I just needed a separate bug number.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33917Make IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL2021-09-16T14:21:51ZteorMake IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.... and DISABLE_ASSERTS_IN_UNIT_TESTS.
It's the only assertion/bug macro that doesn't support these debugging modes. Let's fix that.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33918Stop truncating IPv6 addresses in channel logs2020-06-27T13:47:52ZteorStop truncating IPv6 addresses in channel logschannel_tls_get_remote_desc_method() formats IP addresses and ports, but its buffer is only 32 characters. IPv6 addresses can be up to 41 characters long, and the port is an extra 6 characters.channel_tls_get_remote_desc_method() formats IP addresses and ports, but its buffer is only 32 characters. IPv6 addresses can be up to 41 characters long, and the port is an extra 6 characters.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31812http URL's in docs/comments should be https2021-07-22T16:19:25ZJeremyRandhttp URL's in docs/comments should be httpsThe documentation and comments in Tor's repo have quite a few http URL's that should be changed to https. Patch incoming shortly for this.The documentation and comments in Tor's repo have quite a few http URL's that should be changed to https. Patch incoming shortly for this.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33924Tor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOS2020-06-27T13:47:52ZTracTor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOSOk, so it seems Tor doesn't honor SIGNAL SHUTDOWN anymore. The first Tor version I tested was 0.4.1.5 (first stable of 0.4.1).
Sending it with 0.4.0.6, I see this in the logs:
```
Apr 16 16:31:58.000 [notice] Interrupt: exiting cleanly....Ok, so it seems Tor doesn't honor SIGNAL SHUTDOWN anymore. The first Tor version I tested was 0.4.1.5 (first stable of 0.4.1).
Sending it with 0.4.0.6, I see this in the logs:
```
Apr 16 16:31:58.000 [notice] Interrupt: exiting cleanly.
```
With later Tor versions, this message disappears and the TorThread still hangs around after app wake up.
**Trac**:
**Username**: tlaTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33925Can't compile Tor master as of 2020-04-162020-06-27T13:47:51ZTracCan't compile Tor master as of 2020-04-16I can compile 0.4.3.4-rc without problem now.
Master not so great, though:
```
Ld
/Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug/Tor.framework/Versions
/A/Tor normal x86_64 (in...I can compile 0.4.3.4-rc without problem now.
Master not so great, though:
```
Ld
/Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug/Tor.framework/Versions
/A/Tor normal x86_64 (in target 'Tor-Mac' from project 'Tor') cd
/Users/berhart/workspace/gp/Tor.framework
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.
/xctoolchain/usr/bin/clang -target x86_64-apple-macos10.9
/-dynamiclib -isysroot
//Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
/platform/Developer/SDKs/MacOSX10.15.sdk
/-L/Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug
/-F/Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug -filelist
//Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Intermediates.noindex/Tor.build/
/Debug/Tor-Mac.build/Objects-normal/x86_64/Tor.LinkFileList
/-install_name @rpath/Tor.framework/Tor -Xlinker -rpath -Xlinker
/@executable_path/../Frameworks -Xlinker -rpath -Xlinker
/@loader_path/../Frameworks -Xlinker -object_path_lto -Xlinker
//Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Intermediates.noindex/Tor.build/
/Debug/Tor-Mac.build/Objects-normal/x86_64/Tor_lto.o -Xlinker
/-export_dynamic -Xlinker -no_deduplicate -fobjc-arc
/-fobjc-link-runtime -fapplication-extension -framework CFNetwork
/-ltor-app -ltor-compress -ltor-evloop -ltor-tls -ltor-crypt-ops
/-lkeccak-tiny -ltor-pubsub -ltor-confmgt -led25519_ref10
/-led25519_donna -lcurve25519_donna -ltor-geoip -ltor-process
/-ltor-buf -ltor-time -ltor-fs -ltor-encoding -ltor-sandbox
/-ltor-container -ltor-net -ltor-thread -ltor-memarea -ltor-math
/-ltor-meminfo -ltor-osinfo -ltor-dispatch -ltor-log -ltor-lock
/-ltor-fdio -ltor-string -ltor-term -ltor-smartlist-core
/-ltor-malloc -ltor-wallclock -ltor-err -ltor-version -ltor-intmath
/-ltor-ctime -lor-trunnel -ltor-trace -lssl -lcrypto -levent
/-levent_core -levent_extra -levent_pthreads -llzma -lz -Xlinker
/-dependency_info -Xlinker
//Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Intermediates.noindex/Tor.build/
/Debug/Tor-Mac.build/Objects-normal/x86_64/Tor_dependency_info.dat
/-o
//Users/berhart/Library/Developer/Xcode/DerivedData/Tor-
/atzjucxhwnhfrqcmzwlymuguursh/Build/Products/Debug/Tor.framework/
/Versions/A/Tor
/
Undefined symbols for architecture x86_64: "_sys_winprocess", referenced
from: _tor_subsystems in libtor-app.a(subsystem_list.o) ld: symbol(s)
not found for architecture x86_64 clang: error: linker command failed
with exit code 1 (use -v to see invocation)
```
See legacy/trac#33837 for more context.
**Trac**:
**Username**: tlaTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33929Tor relay appears offline in Metrics after some times2020-06-27T13:47:51ZTracTor relay appears offline in Metrics after some timesSince at least December 20, my relay appears offline in Metrics after few hours to few days (typically between 3h to 3d). In nyx, all flags disappears. After restarting the service, flags are coming back after few hours and the relay app...Since at least December 20, my relay appears offline in Metrics after few hours to few days (typically between 3h to 3d). In nyx, all flags disappears. After restarting the service, flags are coming back after few hours and the relay appears online again. There is nothing in the log.
My fingerprint:
33D88F331408141F2A2CC563239E54E48F7A211B
Notice that this happens to at least another person, its fingerprint
DAA806E9529D77EF94685FC0E513386EF65B83F8
**Trac**:
**Username**: clementhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33968An option to block Tor2Web traffic2020-06-27T13:47:51ZcypherpunksAn option to block Tor2Web traffichttps://github.com/globaleaks/Tor2web/wiki
http://6zdgh5a5e6zpchdz.onion/blog/security/346-don-t-use-web2tor
How can I reject Tor2Web traffic to my site?
A torrc option such as 'HiddenServiceDenyOnehopRequest 1' will be useful.https://github.com/globaleaks/Tor2web/wiki
http://6zdgh5a5e6zpchdz.onion/blog/security/346-don-t-use-web2tor
How can I reject Tor2Web traffic to my site?
A torrc option such as 'HiddenServiceDenyOnehopRequest 1' will be useful.https://gitlab.torproject.org/tpo/core/tor/-/issues/33978*Proxy and accept *:80 can't coexist2022-06-16T15:22:12Zcypherpunks*Proxy and accept *:80 can't coexistIf *Proxy is 127.0.0.1:1234 and accept is only *:80, Tor won't connect to proxy because its port is not 80.
Tor should connect to *Proxy then set restriction later.If *Proxy is 127.0.0.1:1234 and accept is only *:80, Tor won't connect to proxy because its port is not 80.
Tor should connect to *Proxy then set restriction later.https://gitlab.torproject.org/tpo/core/tor/-/issues/33980Document how to distinguish circuits2020-06-27T13:47:51ZcypherpunksDocument how to distinguish circuitsYou allow one company stats with "C" to distinguish circuits by using "PROXY TCP6" syntax.
Why not allow people to use it instead of keeping it proprietary?
nginx??
$tor_proxy6_id??
Apache??You allow one company stats with "C" to distinguish circuits by using "PROXY TCP6" syntax.
Why not allow people to use it instead of keeping it proprietary?
nginx??
$tor_proxy6_id??
Apache??https://gitlab.torproject.org/tpo/core/tor/-/issues/34040Video but no sound in TOR, Knoppix OS2020-06-27T13:47:50ZTracVideo but no sound in TOR, Knoppix OSI'm running an unaltered Knoppix OS from a USB, on a Dell Latitude E6500 laptop: 2 core, Intel 45 chipset, 64bit capable but only running 32 bit; 512 & 8 GB memory capable but 2 GB memory installed.
"About" in the browser says this is...I'm running an unaltered Knoppix OS from a USB, on a Dell Latitude E6500 laptop: 2 core, Intel 45 chipset, 64bit capable but only running 32 bit; 512 & 8 GB memory capable but 2 GB memory installed.
"About" in the browser says this is Tor 9.0.9, up to date,Firefox 68.7.0esr) (32-bit) up to date.
While in Windows 7 Ultimate (32 bit), sound & video work fine locally & on web in both Firefox and TOR. In Knoppix, both work locally & in Firefox. But in Knoppix in TOR, I can play video but THERE's NO SOUND.
I'm illiterate in unix/debian commands. This is all new to me. Can someone guide me in plainspeak through trying some fixes in Knoppix?
I'm coming up empty on the internet. I would very much appreciate any help. Thank you.
**Trac**:
**Username**: AntiDiluvhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34077Fix compilation with GCC 102020-06-27T13:47:49ZNick MathewsonFix compilation with GCC 10Fedora 32 just came out, and it has GCC 10. (Wow, GCC 10!) We run into warnings there; let's fix them.Fedora 32 just came out, and it has GCC 10. (Wow, GCC 10!) We run into warnings there; let's fix them.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34078Fix compilation warnings with clang 10.0.02020-06-27T13:47:49ZNick MathewsonFix compilation warnings with clang 10.0.0Fedora 32 includes Clang 10.0.0, which is a bit more strict about switch-statement fall-through annotations, and about converting enums to bools. This causes us to hit compilation warnings on all supported Tor versions.
(See also legac...Fedora 32 includes Clang 10.0.0, which is a bit more strict about switch-statement fall-through annotations, and about converting enums to bools. This causes us to hit compilation warnings on all supported Tor versions.
(See also legacy/trac#34077 for the GCC version of this)Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34082Master ticket for client side rendezvous circuit related bugs that cause reac...2021-06-23T17:22:42Zs7rMaster ticket for client side rendezvous circuit related bugs that cause reachability problems in HSv3 landThis is the master ticket for some reachability issues I discovered while stress testing my onionbalance v3 setup. They all occurred while handling HSv3 services.
At least two of them always occur together, but handling them as separate...This is the master ticket for some reachability issues I discovered while stress testing my onionbalance v3 setup. They all occurred while handling HSv3 services.
At least two of them always occur together, but handling them as separate tickets for now and keeping this master ticket to glue them together, since they all mention different stack traces.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34085HSv3: Bug Non-fatal assertion in hs_client.c:518: intro_circ_is_ok2021-07-09T17:22:00Zs7rHSv3: Bug Non-fatal assertion in hs_client.c:518: intro_circ_is_okClient side HSv3 non fatal bug. It occurs like between ~80-120 times in a total of 100.000 built rendezvous circuits:
```
Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:518: intro_circ_is_ok: Non-fata...Client side HSv3 non fatal bug. It occurs like between ~80-120 times in a total of 100.000 built rendezvous circuits:
```
Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:518: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at ../src/feature/hs/hs_client.c:518. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(hs_client_send_introduce1+0x271) [0x55d8749ce5e1] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_ap_handshake_attach_circuit+0x3bd) [0x55d874949d5d] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_ap_attach_pending+0x178) [0x55d87494e108] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
```https://gitlab.torproject.org/tpo/core/tor/-/issues/34130Tor won't start with seccomp sandbox when compiled with --enable-nss2022-07-07T00:49:00ZJigsaw52Tor 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/tpo/core/tor/-/issues/34131Fix logic error in parse_extended_hostname2022-07-07T00:49:00ZNick MathewsonFix logic error in parse_extended_hostnameFound with a new clang warning:
```
log_warn(LD_APP, "Invalid %shostname %s; rejecting",
(*type_out == (ONION_V2_HOSTNAME || ONION_V3_HOSTNAME) ? "onion " : ""),
safe_str_client(address));
```Found with a new clang warning:
```
log_warn(LD_APP, "Invalid %shostname %s; rejecting",
(*type_out == (ONION_V2_HOSTNAME || ONION_V3_HOSTNAME) ? "onion " : ""),
safe_str_client(address));
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34200Refactor tor's circuit path node selection checks2022-07-11T12:31:51ZteorRefactor tor's circuit path node selection checksIn legacy/trac#33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.In legacy/trac#33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.teorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34204Downgrade Travis stem version to a commit where tests pass.2022-07-07T00:49:00ZNick MathewsonDowngrade Travis stem version to a commit where tests pass.Due to https://github.com/torproject/stem/issues/63 our CI is failing. Let's downgrade to a working version of Stem unless it gets fixed right away.
I have a test PR at https://github.com/torproject/tor/pull/1889 ; if CI passes, I'll m...Due to https://github.com/torproject/stem/issues/63 our CI is failing. Let's downgrade to a working version of Stem unless it gets fixed right away.
I have a test PR at https://github.com/torproject/tor/pull/1889 ; if CI passes, I'll make PRs for the other branches and put this in needs_review.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34220Return to stem master once stem issue 63 is resolved.2022-07-07T00:49:00ZNick MathewsonReturn to stem master once stem issue 63 is resolved.When stem fixes https://github.com/torproject/stem/issues/63 , we should revert the travis.yml change of legacy/trac#34204.When stem fixes https://github.com/torproject/stem/issues/63 , we should revert the travis.yml change of legacy/trac#34204.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34232Make summarize_protover_flags() handle NULL and empty string the same2021-09-16T14:21:52ZteorMake summarize_protover_flags() handle NULL and empty string the samesummarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline t...summarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline that functions should treat NULL and "" in similar ways. (Or the difference should be clearly documented.)
So we should ignore "" protovers, the same way we ignore NULL protovers. (Relays with empty protovers won't end up in the consensus, and clients can't use them for anything. So this change should have no real impact.)George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/34233Fix use of == in configure.ac2022-07-07T00:49:00ZNick MathewsonFix use of == in configure.acA user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our legacy/trac#34078 fix.A user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our legacy/trac#34078 fix.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34237Fix spacing in if statement in tor_version_parse()2022-07-07T00:49:00ZNeel Chauhanneel@neelc.orgFix spacing in if statement in tor_version_parse()This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34238Space out some function calls in parse_short_policy()2022-07-07T00:49:01ZNeel Chauhanneel@neelc.orgSpace out some function calls in parse_short_policy()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34245Declare variables in for loops in rend_service_dump_stats()2022-07-07T00:49:01ZNeel Chauhanneel@neelc.orgDeclare variables in for loops in rend_service_dump_stats()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34248Declare HSIntro=5 in Tor's rust protover implementation2021-09-16T14:21:52ZteorDeclare HSIntro=5 in Tor's rust protover implementationMy protover tests for legacy/trac#33222 fail in Rust, because Tor's rust protover doesn't declare HSIntro=5.
I'll do a quick fix in legacy/trac#33222, but I want to leave the backport to David.My protover tests for legacy/trac#33222 fail in Rust, because Tor's rust protover doesn't declare HSIntro=5.
I'll do a quick fix in legacy/trac#33222, but I want to leave the backport to David.https://gitlab.torproject.org/tpo/core/tor/-/issues/34249Make sure the C and Rust protovers can't get out of sync2022-07-07T00:49:01ZteorMake sure the C and Rust protovers can't get out of syncThere is a recurring bug, where we modify the C protover, but forget the Rust protover. (See legacy/trac#34248, legacy/trac#33285, legacy/trac#29631 for similar issues.)
We could fix the underlying issue by fetching the string from a co...There is a recurring bug, where we modify the C protover, but forget the Rust protover. (See legacy/trac#34248, legacy/trac#33285, legacy/trac#29631 for similar issues.)
We could fix the underlying issue by fetching the string from a common location, using C's `#include` or Rust's `include_str!()`.
Then we could test that C and Rust are the same by putting a copy of the protover string in the unit tests, and making sure that it matches the currently supported protocol versions.
This fix and test will be important for proposal 318, because it will modify both protocol version implementations:
https://github.com/torproject/torspec/blob/master/proposals/318-limit-protovers.mdTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33873client: Send back SOCKS extended error F6 in case of bad hostname2021-06-23T17:22:42ZDavid Gouletdgoulet@torproject.orgclient: Send back SOCKS extended error F6 in case of bad hostnameWith the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoie...With the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoieqw.onion`.
Problem is that we only send back the `F6` code if the address was identified, by length, as a v3. We should handle the `BAD_HOSTNAME` error code from `parse_extended_hostname()` and thus send back that extended error.Tor: 0.4.4.x-finalGuinnessGuinnesshttps://gitlab.torproject.org/tpo/core/tor/-/issues/33503LeakSanitizer detected memory leak with Tor 0.4.4.0-alpha-dev (git-6472d9cfdf...2021-06-23T17:22:41ZGeorg KoppenLeakSanitizer detected memory leak with Tor 0.4.4.0-alpha-dev (git-6472d9cfdf1198cf)I hit a memory leak with the latest `tor` code from `master` when using it in Tor Browser.
```
Direct leak of 112 byte(s) in 2 object(s) allocated from:
#0 0x7fdee552d628 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
...I hit a memory leak with the latest `tor` code from `master` when using it in Tor Browser.
```
Direct leak of 112 byte(s) in 2 object(s) allocated from:
#0 0x7fdee552d628 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
#1 0x55e7f567b5fa in tor_malloc_ ../src/lib/malloc/malloc.c:45
#2 0x55e7f567b690 in tor_malloc_zero_ ../src/lib/malloc/malloc.c:71
#3 0x55e7f5478339 in cache_client_desc_new ../src/feature/hs/hs_cache.c:429
#4 0x55e7f5478339 in hs_cache_store_as_client ../src/feature/hs/hs_cache.c:830
#5 0x55e7f5487e50 in client_dir_fetch_200 ../src/feature/hs/hs_client.c:1372
#6 0x55e7f5487e50 in hs_client_dir_fetch_done ../src/feature/hs/hs_client.c:2264
#7 0x55e7f54445fa in handle_response_fetch_hsdesc_v3 ../src/feature/dirclient/dirclient.c:2776
#8 0x55e7f54445fa in connection_dir_client_reached_eof ../src/feature/dirclient/dirclient.c:2202
#9 0x55e7f54445fa in connection_dir_reached_eof ../src/feature/dirclient/dirclient.c:2989
#10 0x55e7f52e5505 in connection_reached_eof ../src/core/mainloop/connection.c:5029
#11 0x55e7f52e5505 in connection_handle_read_impl ../src/core/mainloop/connection.c:3776
#12 0x55e7f52e5505 in connection_handle_read ../src/core/mainloop/connection.c:3788
#13 0x55e7f52f18e0 in conn_read_callback ../src/core/mainloop/mainloop.c:892
#14 0x7fdee528eb0e (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7+0x23b0e)
```
I've attached all the direct/indirect leaks that LeakSanitizer gave me, in case there is more lurking.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34251Fix edge case handling in Rust protover is supported2021-09-16T14:21:52ZteorFix edge case handling in Rust protover is supportedTor's Rust FFI for protocol_list_supports_protocol_or_later() returns true for the empty protocol list.
In C, the function returns false, but this behaviour is undocumented.
This bug doesn't affect protocol_list_supports_protocol() in ...Tor's Rust FFI for protocol_list_supports_protocol_or_later() returns true for the empty protocol list.
In C, the function returns false, but this behaviour is undocumented.
This bug doesn't affect protocol_list_supports_protocol() in Rust, because the Rust error checks are done in a different order.
I'll add a quick fix to legacy/trac#33222, but someone else will need to do the backport. We might want to do the Rust error checks in the same order, too.https://gitlab.torproject.org/tpo/core/tor/-/issues/34254Jenkins fails with hs_service.c:3118:3: error: comparison of unsigned express...2022-07-07T00:49:01ZGeorge KadianakisJenkins fails with hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenk...```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenkins.torproject.org/job/tor-ci-windows-master/659/consoleFull
Seems to be a by-product of legacy/trac#33400.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/34255Doxygen warnings on 0.4.32022-07-07T00:49:01ZNick MathewsonDoxygen warnings on 0.4.3There are some doxygen warnings about unclosed or unbalanced groups.There are some doxygen warnings about unclosed or unbalanced groups.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34299man page has wrong default for MinUptimeHidServDirectoryV22022-07-07T00:49:01ZRoger Dingledineman page has wrong default for MinUptimeHidServDirectoryV2In legacy/trac#14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the ...In legacy/trac#14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the man page.Tor: 0.4.3.x-final