Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-01-10T18:36:20Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40383daily abort in tor 0.4.5.7, 0.4.6.1-alpha, and 0.4.6.2-alpha [Assertion end >...2023-01-10T18:36:20ZScott Bennettdaily abort in tor 0.4.5.7, 0.4.6.1-alpha, and 0.4.6.2-alpha [Assertion end > start failed in create_voting_schedule]### Summary
I was running 0.4.5.2-alpha with no problems. After I upgraded tor to 0.4.6.1-alpha,
tor crashed in under 24 hours. After the third such crash, I switched to 0.4.5.7,
naively expecting it to be a "stable" release. That vers...### Summary
I was running 0.4.5.2-alpha with no problems. After I upgraded tor to 0.4.6.1-alpha,
tor crashed in under 24 hours. After the third such crash, I switched to 0.4.5.7,
naively expecting it to be a "stable" release. That version, too, crashes with the
same set of error messages. I have now upgraded to 0.4.6.2-alpha, and the same bug
is present. I am running tor on a FreeBSD 11.4-STABLE system.
### Steps to reproduce:
1. Install one of the afflicted versions of tor onto a FreeBSD 11.4-STABLE system. I do not
know whether later versions of FreeBSD would get a different result, but given the abort
messages, I suspect not.
2. Start tor.
3. Wait until 6 p.m. CDT (2300Z). The abort will occur before 7 p.m. CDT (0000Z).
### What is the current bug behavior?
During startup and operation everything appears to be normal. However, these versions
of tor always abort every day between 6 p.m. and 7 p.m. CDT (2300Z and 0000Z) with the
same group of error messages being written to /var/log/notices.
The startup messages look as follows.
```
May 08 19:21:24.633 [notice] Tor 0.4.6.2-alpha opening log file.
May 08 19:21:24.601 [notice] We compiled with OpenSSL 101010bf: OpenSSL 1.1.1k 25 Mar 2021 and we are running with OpenSSL 101010bf: 1.1.1k. These two versions should be binary compatible.
May 08 19:21:24.604 [notice] Tor 0.4.6.2-alpha running on FreeBSD with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.9 and Unknown N/A as libc.
May 08 19:21:24.604 [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 08 19:21:24.604 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 08 19:21:24.604 [notice] Read configuration file "/usr/local/etc/tor/torrc".
May 08 19:21:24.616 [notice] You configured a non-loopback address '10.1.1.1:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
May 08 19:21:24.616 [notice] Opening Socks listener on 127.0.0.1:9050
May 08 19:21:24.616 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050
May 08 19:21:24.616 [notice] Opening Socks listener on 10.1.1.1:9050
May 08 19:21:24.616 [notice] Opened Socks listener connection (ready) on 10.1.1.1:9050
May 08 19:21:24.616 [notice] Opening Control listener on 127.0.0.1:9051
May 08 19:21:24.616 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
May 08 19:21:24.616 [notice] Opening OR listener on 0.0.0.0:32323
May 08 19:21:24.616 [notice] Opened OR listener connection (ready) on 0.0.0.0:32323
May 08 19:21:24.616 [notice] Opening Directory listener on 0.0.0.0:32326
May 08 19:21:24.616 [notice] Opened Directory listener connection (ready) on 0.0.0.0:32326
May 08 19:21:24.640 [notice] Not disabling debugger attaching for unprivileged users.
May 08 19:21:25.419 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
May 08 19:21:25.593 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
May 08 19:21:25.756 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
May 08 19:21:25.907 [notice] Your Tor server's identity key fingerprint is 'MYCROFTsOtherChild 0861F4966E199C0BA9DB1D904DB4BC843508F12C'
May 08 19:21:25.907 [notice] Your Tor server's identity key ed25519 fingerprint is 'MYCROFTsOtherChild hYNLQhYYu0FRDfZGPVW3jFPW27tHY6fZm0GiFP2YkPE'
May 08 19:21:25.907 [notice] Bootstrapped 0% (starting): Starting
May 08 19:21:43.556 [notice] Starting with guard context "default"
May 08 19:21:44.605 [notice] Bootstrapped 5% (conn): Connecting to a relay
May 08 19:21:44.718 [notice] Bootstrapped 10% (conn_done): Connected to a relay
May 08 19:21:44.962 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
May 08 19:21:45.447 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
May 08 19:21:45.448 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
May 08 19:21:45.448 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
May 08 19:21:45.448 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
May 08 19:21:48.184 [notice] Bootstrapped 100% (done): Done
May 08 19:21:48.185 [notice] Now checking whether IPv4 ORPort 98.193.69.56:32323 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
May 08 19:21:48.649 [notice] Self-testing indicates your ORPort 98.193.69.56:32323 is reachable from the outside. Excellent. Publishing server descriptor.
May 08 19:39:45.296 [notice] Performing bandwidth self-test...done.
```
The abort messages follow. It does not appear to matter what time of day tor is started.
It always aborts during that hour at the start of the evening, and the exact time seems to be
quasi-random and may coincide with some quasi-hourly event, such as downloading directory
updates or consensus files.
```
May 09 18:21:45.586 [notice] Heartbeat: Tor's uptime is 23:00 hours, with 88 circuits open. I've sent 1.18 GB and received 1.46 GB. I've received 12680 connections on IPv4 and 0 on IPv6. I've made 11044 connections with IPv4 and 0 with IPv6.
May 09 18:21:45.620 [notice] While bootstrapping, fetched this many bytes: 35042 (consensus network-status fetch); 500 (microdescriptor fetch)
May 09 18:21:45.620 [notice] While not bootstrapping, fetched this many bytes: 13502874 (server descriptor fetch); 1080 (server descriptor upload); 1780039 (consensus network-status fetch); 89127 (microdescriptor fetch)
May 09 18:21:45.620 [notice] Circuit handshake stats since last time: 11/11 TAP, 1449/1449 NTor.
May 09 18:21:45.620 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 511 v4 connections; initiated 10070 and received 11411 v5 connections.
May 09 18:21:45.620 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected.
May 09 18:23:46.805 [err] tor_assertion_failed_: Bug: src/feature/dirauth/voting_schedule.c:64: create_voting_schedule: Assertion end > start failed; aborting. (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: Tor 0.4.6.2-alpha: Assertion end > start failed in create_voting_schedule at src/feature/dirauth/voting_schedule.c:64: . Stack trace: (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1107fac <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x11132a2 <tor_assertion_failed_+0x142> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x10e96a6 <dirauth_sched_recalculate_timing+0x1e6> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x109c113 <networkstatus_set_current_consensus+0xed3> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x11d96cc <connection_dir_reached_eof+0x1b6c> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x11acf26 <connection_handle_read+0xbe6> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1090050 <connection_add_impl+0x240> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1c1bada8a <event_base_assert_ok_nolock_+0xc3a> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1c1ba8eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1092465 <do_main_loop+0x135> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.807 [err] Bug: 0x108d89c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.807 [err] Bug: 0x108c22e <tor_main+0x6e> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
```
### What is the expected behavior?
I expect tor not to abort and instead to run until either I shut it down or the OS crashes
for any reason.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
As stated above, the versions I know to be affected are 0.4.5.7, 0.4.6.1-alpha, and
0.4.6.2-alpha.
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10,
Ubuntu Xenial, FreeBSD 12.2, etc.
As stated above, this problem is occurring on FreeBSD 11.4-STABLE. I have added an
entry to /etc/crontab to restart tor every evening at 7:01 p.m. CDT (2301Z), which works,
but does not prevent sudden breakage of about 400 to 2000 connections when tor aborts, and
means that my relay can never get a Stable flag. (The authorities stopped giving it a
HSDir flag months ago for no reason apparent to me, as well, but that appears to be a problem unrelated to the bug reported here.)
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
I installed each version using portmaster(8) to install/upgrade from the FreeBSD
11-STABLE ports tree, so portmaster compiled each version locally. Other than the kinds of
differences that show up when not using a "reproducible build" procedure, they are the same
as if installed by pkg(8).
### Relevant logs and/or screenshots
See above.
### Possible fixesTor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40549Test failure in protover.c (main)2022-12-10T17:58:55ZDavid Gouletdgoulet@torproject.orgTest failure in protover.c (main)protover/supported_protocols:
FAIL /builds/dgoulet/tor/src/test/test_protover.c:427: assert(protocol_list_supports_protocol(supported_protocols, PRT_HSINTRO, PROTOVER_HS_INTRO_V2))
[supported_protocols FAILED]
Due to latest protove...protover/supported_protocols:
FAIL /builds/dgoulet/tor/src/test/test_protover.c:427: assert(protocol_list_supports_protocol(supported_protocols, PRT_HSINTRO, PROTOVER_HS_INTRO_V2))
[supported_protocols FAILED]
Due to latest protover change where `HSIntro` went to minimum of `4`.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40472Be more particular about limit argument to smartlist_split_string()2022-10-11T23:39:35ZNick MathewsonBe more particular about limit argument to smartlist_split_string()OSS-Fuzz claims that there's a ridiculously slow runtime for calling "diff-apply" when the line with the hashes has a whole bunch of fields in it.
That's because we call `smartlist_split_string()` with a final argument of "0", which mea...OSS-Fuzz claims that there's a ridiculously slow runtime for calling "diff-apply" when the line with the hashes has a whole bunch of fields in it.
That's because we call `smartlist_split_string()` with a final argument of "0", which means "no limit on the number of pieces to split this string into". That results in a whole bunch of allocations, which are slow under the AddressSanitizer that the fuzzer uses. I don't think this one is actually a great CPU DOS vector in the wild: malloc() isn't that slow when you aren't using asan.
But nonetheless we should go through all our calls to smartlist_split_string(), see which ones don't have a limit, and maybe impose a limit on them.
The ~Backport label on this ticket is tentative: we might want to backport important fixes we find here, if we think they might lead to problems down the line.Tor: 0.4.5.x-post-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40233Assertion when starting an IPv4-only bridge on 0.4.5.2-alpha2022-07-07T00:48:32ZNeel Chauhanneel@neelc.orgAssertion when starting an IPv4-only bridge on 0.4.5.2-alphaWhen I set up a bridge on FreeBSD, I got this issue.
Jan 01 21:10:44.000 [notice] Bootstrapped 0% (starting): Starting
Jan 01 21:10:44.000 [notice] Starting with guard context "default"
Jan 01 21:10:44.000 [notice] Registere...When I set up a bridge on FreeBSD, I got this issue.
Jan 01 21:10:44.000 [notice] Bootstrapped 0% (starting): Starting
Jan 01 21:10:44.000 [notice] Starting with guard context "default"
Jan 01 21:10:44.000 [notice] Registered server transport 'obfs4' at '[::]:80'
Jan 01 21:10:45.000 [warn] tor_bug_occurred_: Bug: src/feature/relay/relay_find_addr.c:201: relay_addr_learn_from_dirauth: Non-fatal assertion !(!node) failed. (on Tor 0.4.5.2-alpha )
Jan 01 21:10:
Jan 01 21:10:45.000 [warn] Bug: 0x11a2ad2 <router_build_fresh_descriptor+0x2a2> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x11a1f3f <router_rebuild_descriptor+0x6f> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x11a1d49 <consider_publishable_server+0x39> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1225714 <reschedule_descriptor_update_check+0x274> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x122a77a <periodic_event_connect+0x10a> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x8013fe0ed <event_base_assert_ok_nolock_+0xa5d> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x8013fa09c <event_base_loop+0x53c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x116c861 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1155cbc <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1154651 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1154309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
This happened on FreeBSD 12.2 on a bridge on Microsoft Azure. Tor was installed via `pkg` and I do not have a local-link IPv6 address.Tor: 0.4.5.x-post-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40410ratelim.h:55:27: error: initializer element is not constant2022-07-07T00:47:10Zacidsysratelim.h:55:27: error: initializer element is not constant### Summary
### Steps to reproduce:
1. Clone latest master (0.4.7.0-alpha-dev as of 10/06/2021)
2. ./autogen.sh
3. ./configure
4. make
### What is the current bug behavior?
```
CC src/feature/dircache/dircache.o
CC ...### Summary
### Steps to reproduce:
1. Clone latest master (0.4.7.0-alpha-dev as of 10/06/2021)
2. ./autogen.sh
3. ./configure
4. make
### What is the current bug behavior?
```
CC src/feature/dircache/dircache.o
CC src/feature/dircache/dirserv.o
CC src/feature/dirclient/dirclient.o
In file included from ./src/core/or/or.h:50:0,
from src/feature/dirclient/dirclient.c:13:
src/feature/dirclient/dirclient.c: In function ‘dir_client_decompress_response_body’:
./src/lib/log/ratelim.h:55:27: error: initializer element is not constant
#define RATELIM_INIT(r) { (r), 0, 0, 0 }
^
src/feature/dirclient/dirclient.c:1911:38: note: in expansion of macro ‘RATELIM_INIT’
static ratelim_t warning_limit = RATELIM_INIT(LOG_INTERVAL);
^~~~~~~~~~~~
./src/lib/log/ratelim.h:55:27: note: (near initialization for ‘warning_limit.rate’)
#define RATELIM_INIT(r) { (r), 0, 0, 0 }
^
src/feature/dirclient/dirclient.c:1911:38: note: in expansion of macro ‘RATELIM_INIT’
static ratelim_t warning_limit = RATELIM_INIT(LOG_INTERVAL);
^~~~~~~~~~~~
make[1]: *** [Makefile:11154: src/feature/dirclient/dirclient.o] Error 1
make[1]: Leaving directory '/home/georg/new/tor'
make: *** [Makefile:6180: all] Error 2
```
### What is the expected behavior?
Either the program should compile without any errors, or configure should inform about dependency issues.
### Failed Environment
- openSUSE Leap 15.2
- Tor 0.4.7.0-alpha-dev via git clone
- GNU Autoconf 2.69
- GNU Make 4.2.1
- gcc (SUSE Linux) 7.5.0
### Working environment
- openSUSE Tumbleweed
- Tor 0.4.7.0-alpha-dev via git clone
- autoconf (GNU Autoconf) 2.69
- GNU Make 4.3
- gcc (SUSE Linux) 10.3.0
### Possible fixes
No solution or workaround found so far.
### Suggestion
In case the compatibility with older (stable) distributions is not restorable, an exemption should be implemented in configureTor: 0.4.5.x-post-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40317Cannot SAVECONF when the seccomp sandbox is enabled2022-07-07T00:47:10ZanonymCannot SAVECONF when the seccomp sandbox is enabled### Summary
Issuing a `SAVECONF` to `tor` when the seccomp sandbox is enabled fails.
### Steps to reproduce:
1. Start `tor` with `Sandbox 1` set and controller access
2. Send `SAVECONF` via the controller
### What is the current bug ...### Summary
Issuing a `SAVECONF` to `tor` when the seccomp sandbox is enabled fails.
### Steps to reproduce:
1. Start `tor` with `Sandbox 1` set and controller access
2. Send `SAVECONF` via the controller
### What is the current bug behavior?
Sending a `SAVECONF` currently results in this answer:
```
250 OK
551 Unable to write configuration to disk.
250 closing connection
```
and `tor` logs:
```
Mar 05 11:31:28.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.orig.1 (on Tor 0.4.5.6 )
Mar 05 11:31:28.000 [notice] Renaming old configuration file to "/etc/tor/torrc.orig.1"
Mar 05 11:31:28.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.orig.1 (on Tor 0.4.5.6 )
Mar 05 11:31:28.000 [warn] Couldn't rename configuration file "/etc/tor/torrc" to "/etc/tor/torrc.orig.1": Operation not permitted
```
and unsurprisingly the current `tor` configuration was not saved to `torrc`.
### What is the expected behavior?
`SAVECONF` should work even when the seccomp sandbox is enabled.
### Environment
I tried with both `tor` 0.4.4.6 and 0.4.5.6 on an Debian Buster, using your `.deb`:s.
### Relevant logs and/or screenshots
Except the log I posted above, sometimes I saw this instead but I don't know why it's different:
```
Mar 05 12:06:00.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.tmp (on Tor 0.4.4.6 )
Mar 05 12:06:00.000 [warn] Couldn't open "/etc/tor/torrc.tmp" (/etc/tor/torrc) for writing: Operation not permitted
```Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40228Make it possible to disable dormant mode altogether2022-05-13T08:07:54ZPhilipp Winterphw@torproject.orgMake it possible to disable dormant mode altogetherThere is currently no configuration option to disable tor's dormant mode. One can prevent it indirectly by 1) occasionally sending traffic over the SOCKS port, 2) telling tor to set up an onion service, or by 3) sending tor a `SIGNAL ACT...There is currently no configuration option to disable tor's dormant mode. One can prevent it indirectly by 1) occasionally sending traffic over the SOCKS port, 2) telling tor to set up an onion service, or by 3) sending tor a `SIGNAL ACTIVE` (but that only wakes up tor when it's sent from a control port connection that was established _after_ tor went dormant).
In the context of bridgestrap, it would be convenient to simply disable dormant mode rather than deal with the above workarounds. Bridgestrap tests bridges by sending a `SETCONF [bridge]` to tor's control port; it never performs any client activity.
TL;DR: I'd like to have a configuration option that tells tor to never go dormant.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40515pathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state ne...2022-04-14T13:39:03ZRoger Dingledinepathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently open.On my Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589, I can induce this log message:
```
Nov 11 07:07:06.365 [notice] pathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently ...On my Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589, I can induce this log message:
```
Nov 11 07:07:06.365 [notice] pathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently open. (on Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589)
Nov 11 07:07:06.392 [notice] pathbias_mark_use_success(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently open. (on Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589)
Nov 11 07:07:06.393 [notice] pathbias_count_use_attempt(): Bug: Used circuit 8 is in strange path state new. Circuit is a General-purpose client currently open. (on Tor 0.4.7.2-alpha-dev 9d8b0c5bdc6f7589)
```
The way I do it is by going into the controller, and doing an
```
extendcircuit 0 moria1,CalyxInstitute14
mapaddress 10.10.10.11=128.31.0.34.0011BD2485AD45D984EC4159C88FC066E5E3300E.exit
```
and then from my shell, doing a
```
torify telnet 10.10.10.11 80
```
I successfully connect via that exit to the desired webserver. But the circuit that Tor made via extendcircuit hasn't set whatever flags or the like it was expecting to have set.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40141unit test fail "assert(smartlist_len(results) OP_EQ sizeof(results_test11)/si...2022-03-18T18:03:52ZRoger Dingledineunit test fail "assert(smartlist_len(results) OP_EQ sizeof(results_test11)/sizeof(*results_test11)): 6 vs 3"'make test' on git master (commit e687707) on moria (old-school rhel6) has this error:
```
util/glob:
FAIL src/test/test_util.c:4578: assert(smartlist_len(results) OP_EQ sizeof(results_test11)/sizeof(*results_test11)): 6 vs 3
[glob F...'make test' on git master (commit e687707) on moria (old-school rhel6) has this error:
```
util/glob:
FAIL src/test/test_util.c:4578: assert(smartlist_len(results) OP_EQ sizeof(results_test11)/sizeof(*results_test11)): 6 vs 3
[glob FAILED]
```
Looks like the failure went in with commit 34fa2c4d as part of #25140.
Do the unit tests have any "show their work" files somewhere, or is the next step to
add more prints and stuff to figure out what's going on?
I also have a second failure,
```
config/include_wildcards:
FAIL src/test/test_config.c:6106: assert(len OP_EQ 2): 3 vs 2
[include_wildcards FAILED]
```
which seems related to the same commit.Tor: 0.4.5.x-post-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40175zlib compression bomb warning in notices.log on a middle relay2022-03-17T16:39:34ZGuinnesszlib compression bomb warning in notices.log on a middle relayMultiple users starting from at least 0.4.4.5 and further (0.4.5.1-alpha) have some warning concerning zlib compression bombs.
Here is an example from one of my relays (I have the same on all my relays)
```
Nov 02 05:30:55.000 [warn] Pos...Multiple users starting from at least 0.4.4.5 and further (0.4.5.1-alpha) have some warning concerning zlib compression bombs.
Here is an example from one of my relays (I have the same on all my relays)
```
Nov 02 05:30:55.000 [warn] Possible compression bomb; abandoning stream.
Nov 02 05:30:55.000 [warn] Possible zlib bomb; abandoning stream.
Nov 02 05:30:56.000 [warn] Possible compression bomb; abandoning stream.
Nov 02 05:31:00.000 [warn] Possible compression bomb; abandoning stream.
Nov 02 05:31:00.000 [warn] Possible compression bomb; abandoning stream.
Nov 02 05:31:00.000 [warn] Possible compression bomb; abandoning stream.
Nov 02 05:31:55.000 [warn] Possible compression bomb; abandoning stream.
Nov 02 05:31:56.000 [warn] Possible compression bomb; abandoning stream.
```
I don't know if it is a new feature of Tor or if this is an ongoing attack.
I'll also mail the tor-relays@ ML in order to see how many people are affected.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40557New 045 and 046 releases with geoip and fallbackdir2022-02-04T18:04:52ZDavid Gouletdgoulet@torproject.orgNew 045 and 046 releases with geoip and fallbackdirIt appears that the latest 045 (0.4.5.11) and 046 (0.4.6.9) failed to have the GeoIP and fallbackdir changes merged to them.
This was reported by @syphyr in !520 from which we discovered that we likely failed to merge forward those chan...It appears that the latest 045 (0.4.5.11) and 046 (0.4.6.9) failed to have the GeoIP and fallbackdir changes merged to them.
This was reported by @syphyr in !520 from which we discovered that we likely failed to merge forward those changes and instead we likely only ran the `git merge -s ours` command leading to taking the history but not the changes.
Note that the `-s ours` is done at the step of version bump of each branch.
This will require us to do two new releases.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40552metrics: Prometheus output needs to quote the label's value2022-02-03T17:06:13ZDavid Gouletdgoulet@torproject.orgmetrics: Prometheus output needs to quote the label's valueFrom tor-relays@: https://lists.torproject.org/pipermail/tor-relays/2022-January/020252.html
Bottom line is that we need to quote the label value with `"<value>"`. Else it leads to:
`msg="Append failed" err="expected label value, got \...From tor-relays@: https://lists.torproject.org/pipermail/tor-relays/2022-January/020252.html
Bottom line is that we need to quote the label value with `"<value>"`. Else it leads to:
`msg="Append failed" err="expected label value, got \"INVALID\"`Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40500CI: Exclude HSv2 Stem tests in 0452022-01-20T19:24:11ZDavid Gouletdgoulet@torproject.orgCI: Exclude HSv2 Stem tests in 045In 046+, we've disabled a set of version specific Stem tests since we've removed the code. We need to do the same in 045.In 046+, we've disabled a set of version specific Stem tests since we've removed the code. We need to do the same in 045.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40355Problem with MSYS2 build: AC_PROG_CC_C99 is obsolete (also printf attribute i...2021-11-08T14:14:52ZVortProblem with MSYS2 build: AC_PROG_CC_C99 is obsolete (also printf attribute is printf-dependent)Because I was feeling the need to upgrade OpenSSL, I decided to make a rebuild of my 0.4.5.7 binary.
Update of OpenSSL in MSYS2 usually done with single command: `pacman -Syuu`.
This time there was a problem with GPG keys.
After so...Because I was feeling the need to upgrade OpenSSL, I decided to make a rebuild of my 0.4.5.7 binary.
Update of OpenSSL in MSYS2 usually done with single command: `pacman -Syuu`.
This time there was a problem with GPG keys.
After solving it, I found that Tor fails to build:
```
Vort@Vort-PC MINGW64 /e/_Projects/_Test/tor
$ ./autogen.sh && ./configure --disable-unittests --disable-asciidoc --disable-module-dirauth && make
/usr/bin/autoreconf
configure.ac:444: warning: The macro `AC_PROG_CC_C99' is obsolete.
configure.ac:444: You should run autoupdate.
../autoconf-2.71/lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...
configure.ac:444: the top level
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
```
Removing of `AC_PROG_CC_C99` line from `configure.ac` solved this particular problem, but I think that maybe more correct solutions exists.
Also buildlog was flooded with format-related messages like this:
```
src/lib/wallclock/time_to_tm.c:108:27: warning: too many arguments for format [-Wformat-extra-args]
```
Maybe it should be addressed too.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40494tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: dire...2021-11-03T13:55:05Zsamip537tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed;### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the follo...### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the following contents:
```
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
ORPort 443
ORPort [2001:DB8::1]:443
RelayBandwidthRate 5 MB
RelayBandwidthBurst 10 MB
AccountingMax 5 TB
AccountingStart month 3 15:00
DirPort [2001:DB8::1]:80
ExitPolicy reject *:*
```
5. Have it crash after 3-10 minutes from bandwidth self-test.
### What is the current bug behavior?
The whole Tor client crashes when set with DirPort with IPv6 address in brackets followed by port.
### What is the expected behavior?
It would not crash.
### Environment
- Which version of Tor are you using? 0.4.5.10
- Which operating system are you using? Debian 11, in an LXC container
- Which installation method did you use? Distribution package
### Relevant logs and/or screenshots
```
Oct 22 06:42:35 torrelay systemd[1]: Started Anonymizing overlay network for TCP.
Oct 22 06:42:35 torrelay Tor[6069]: Signaled readiness to systemd
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 5% (conn): Connecting to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Opening Socks listener on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opened Socks listener connection (ready) on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opening Control listener on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Opened Control listener connection (ready) on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Unable to find IPv4 address for ORPort 443. You might want to specify IPv6Only to it or set an explicit address or set Address.
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 10% (conn_done): Connected to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 14% (handshake): Handshaking with a relay
Oct 22 06:42:36 torrelay Tor[6069]: External address seen and suggested by a directory authority: <snip>
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Oct 22 06:42:37 torrelay Tor[6069]: Bootstrapped 100% (done): Done
Oct 22 06:43:36 torrelay Tor[6069]: Not advertising Directory Service support (Reason: AccountingMax enabled)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv4 ORPort <snip>:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv6 ORPort [2001:DB8::1]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Self-testing indicates your ORPort [2001:DB8::1]:443 is reachable from the outside. Excellent.
Oct 22 06:45:37 torrelay Tor[6069]: Self-testing indicates your ORPort <snip>:443 is reachable from the outside. Excellent.
Oct 22 06:45:39 torrelay Tor[6069]: Performing bandwidth self-test...done.
Oct 22 06:48:37 torrelay Tor[6069]: tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed; aborting. (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: Tor 0.4.5.10: Assertion or_addr_port->port || dir_addr_port->port failed in directory_initiate_request at ../src/feature/dirclient/dirclient.c:1257: . Stack trace: (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(log_backtrace_impl+0x6c) [0x557a907880] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_assertion_failed_+0x124) [0x557a914364] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(directory_initiate_request+0x714) [0x557a9d5424] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(router_do_reachability_checks+0x184) [0x557a8d27b8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(connection_dir_reached_eof+0x13cc) [0x557a9d783c] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x1993e4) [0x557a9a93e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x68570) [0x557a878570] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(+0x234e4) [0x7f9e42e4e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x50c) [0x7f9e42ef84] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(do_main_loop+0xec) [0x557a8799e0] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_run_main+0x1c0) [0x557a8751b4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_main+0x54) [0x557a871734] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(main+0x20) [0x557a871220] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8) [0x7f9dd5c218] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x612a8) [0x557a8712a8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Main process exited, code=killed, status=6/ABRT
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Failed with result 'signal'.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 5.
Oct 22 06:48:37 torrelay systemd[1]: Stopped Anonymizing overlay network for TCP.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
```
### Possible fixesTor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40382Sandbox failures with glibc 2.332021-11-01T14:50:41ZNick MathewsonSandbox failures with glibc 2.33It appears that glibc 2.33 is using yet another new set of system calls to implement our old friends. In particular I'm seeing `newfstatat` used to implement both stat and fstat.
Incidentally, this change will probably mean that we c...It appears that glibc 2.33 is using yet another new set of system calls to implement our old friends. In particular I'm seeing `newfstatat` used to implement both stat and fstat.
Incidentally, this change will probably mean that we can't allow fstat() without allowing _all_ stat() calls in the sandbox, since the behavior of using `fstatat` to implement `fstat` or seems to depend on the presence of `AT_EMPTY_PATH` *and* on having an empty string for the path argument, and we can't detect a glibc-generated empty string from the seccomp sandbox.
So, how bad is it to allow all stat() calls from the sandbox? Probably it's not so great, but I don't see a choice here.Tor: 0.4.5.x-post-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40185relay with 0.4.5.1-alpha-dev (git-dd119b277b66c1a7) ignores -INT and -USR12021-10-22T14:17:38Ztoralfrelay with 0.4.5.1-alpha-dev (git-dd119b277b66c1a7) ignores -INT and -USR1It happened here 2x in a row that a relay here could only be terminated (-HUP worked all the time for what it is worth).
OS is a hardened Linux.
FWIW there are 2 relays running at the same hardware under a hardened Gentoo Linux.
The one...It happened here 2x in a row that a relay here could only be terminated (-HUP worked all the time for what it is worth).
OS is a hardened Linux.
FWIW there are 2 relays running at the same hardware under a hardened Gentoo Linux.
The one which is listing at default ports (80 and 443) behaves fine, the other (9001 and 9030 and being a FallbackDir too) however is affected by this issue.
Update: It is independent from being a FallbackDir or not, with bc6c37b202e907ed now the other relay refused to restart - and today -TERM was ignored too at 1 relay.
Nowadays a _kill -HUP_ is ignored after an uptime of only few hours.
I use this cronjob for now to keep both relays aware of signals
```
@hourly (/sbin/rc-service tor reload; /sbin/rc-service tor2 reload) 1>/dev/null
```Tor: 0.4.5.x-post-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34088circuit_build_times_update_alpha(): Bug: Could not determine largest build time2021-08-19T20:59:05Zs7rcircuit_build_times_update_alpha(): Bug: Could not determine largest build timeI don't think this is HSv3 ONLY related, but I can only make it happen while building large amounts of rendezvous circuits with reasonable concurrency (over 50). I am not assigning the tor-hs keyword for this reason, but sticking it to s...I don't think this is HSv3 ONLY related, but I can only make it happen while building large amounts of rendezvous circuits with reasonable concurrency (over 50). I am not assigning the tor-hs keyword for this reason, but sticking it to same master parent ticket.
All lines are the same. It is seen for like 130-160 times during the build of little over 100.000 rendezvous circuits.
```
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 136 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 137 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 138 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 139 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 140 circuits. (on Tor 0.4.4.0-alpha-dev )
```
EDIT: All lines are the same except it always abandons 0 out of N circuits and N is always different of course, increasing with +1 most of the times until the Bug warn disappears.Tor: 0.4.5.x-post-stableMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40360tor stalls at 25% bootstrapped unless there is a fingerprint in the Bridge line2021-05-26T12:25:01ZCecylia Bocovichtor stalls at 25% bootstrapped unless there is a fingerprint in the Bridge lineAccording to the [tor man page](https://2019.www.torproject.org/docs/tor-manual.html.en), the `Bridge` option of the client's torrc file does not require a fingerprint:
```
If "fingerprint" is provided (using the same format as for
DirAu...According to the [tor man page](https://2019.www.torproject.org/docs/tor-manual.html.en), the `Bridge` option of the client's torrc file does not require a fingerprint:
```
If "fingerprint" is provided (using the same format as for
DirAuthority), we will verify that the relay running at that
location has the right fingerprint.
```
However, ever since the fixes for #40106 (I did a git bisect, but couldn't narrow down exactly which commit was the culprit due to other transport related bugs), my bootstrap stalls at 25% unless a fingerprint is provided (with an empty datadir it stalls at 70% weirdly). I have tested this with both Snowflake and Obfs4.
If there's a good security reason to require the fingerprint, we should update the manpage, and also make sure that we always distribute the fingerprint with bridge lines. I'd prefer not requiring the fingerprint since some transports like snowflake have the proxies, not the client, decide which bridge to connect to.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40370config: MetricsPort seems to keep wanting to open2021-05-17T13:04:35ZDavid Gouletdgoulet@torproject.orgconfig: MetricsPort seems to keep wanting to openSeveral users have reported this problem and I just stumble on it by enabling `MetricsPort` on a relay:
```
Apr 15 14:16:56.005 [notice] Opening Metrics listener on 127.0.0.1:9090 ...Several users have reported this problem and I just stumble on it by enabling `MetricsPort` on a relay:
```
Apr 15 14:16:56.005 [notice] Opening Metrics listener on 127.0.0.1:9090
Apr 15 14:16:56.005 [notice] Opened Metrics listener connection (ready) on 127.0.0.1:9090
[...]
Apr 15 14:17:00.370 [notice] Opening Metrics listener on 127.0.0.1:9090
Apr 15 14:17:00.370 [warn] Could not bind to 127.0.0.1:9090: Address already in use. Is Tor already running?
Apr 15 14:18:00.375 [notice] Opening Metrics listener on 127.0.0.1:9090
Apr 15 14:18:00.375 [warn] Could not bind to 127.0.0.1:9090: Address already in use. Is Tor already running?
...
```
The port works and is open but every minute, Tor seems to retry to open it. Possible backport candidate.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org