Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-02-04T18:04:52Zhttps://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/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/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/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/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/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/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/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/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/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.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40365Incorrect token pasting in test_connection.c2021-05-10T17:06:21ZNick MathewsonIncorrect token pasting in test_connection.cJust noticed that some appveyor tests are failing related to the CONNECTION_TESTCASE_ARG macro.Just noticed that some appveyor tests are failing related to the CONNECTION_TESTCASE_ARG macro.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://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/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/40342Tor 0.4.5.7 minor log spam; Unable to find IPv6 address for ORPort2021-03-23T18:53:26ZerTor 0.4.5.7 minor log spam; Unable to find IPv6 address for ORPortThats after 6 hours uptime. Initial remark in logs would be ok. Repeating it over and over again after that, this kinda isnt. So there is no ipv6 address configured. Is that illegal? Can you still function? Take a hint, will you? Just m...Thats after 6 hours uptime. Initial remark in logs would be ok. Repeating it over and over again after that, this kinda isnt. So there is no ipv6 address configured. Is that illegal? Can you still function? Take a hint, will you? Just my 2 cents.
```
Mar 17 15:19:36.825 [notice] Tor 0.4.5.7 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1i, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
...
Mar 17 15:20:01.000 [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address.
...
Mar 17 16:20:02.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [62 similar message(s) suppressed in last 3660 seconds]
Mar 17 17:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
Mar 17 18:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3600 seconds]
Mar 17 19:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
Mar 17 20:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
Mar 17 21:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
```Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40335tor-0.4.5.6: SunOS / OpenIndiana test failure / unittest_part8.sh2021-05-16T16:23:34Zsvschmeltor-0.4.5.6: SunOS / OpenIndiana test failure / unittest_part8.shWhen running the self tests for tor-0.4.5.6 on SunOS OpenIndiana Hipster, I see following failure:
```
gmake test
....
PASS: src/test/unittest_part5.sh
PASS: src/test/unittest_part6.sh
PASS: src/test/unittest_part7.sh
FAIL: src/test/un...When running the self tests for tor-0.4.5.6 on SunOS OpenIndiana Hipster, I see following failure:
```
gmake test
....
PASS: src/test/unittest_part5.sh
PASS: src/test/unittest_part6.sh
PASS: src/test/unittest_part7.sh
FAIL: src/test/unittest_part8.sh
PASS: src/test/test_ntor.sh
PASS: src/test/test_hs_ntor.sh
PASS: src/test/test_bt.sh
....
============================================================================
Testsuite summary for tor 0.4.5.6
============================================================================
# TOTAL: 33
# PASS: 30
# SKIP: 2
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
....
```
Error:
```
FAIL: src/test/unittest_part8.sh
================================
....
util/listdir: OK
util/glob:
FAIL /export/home/svschmel/oi-userland/components/network/tor/tor-0.4.5.6/src/test/test_util.c:4572: assert(smartlist_len(results) OP_EQ sizeof(results_test10)/sizeof(*results_test10)): 0 vs 1
[glob FAILED]
util/get_glob_opened_files: OK
util/parent_dir: OK
util/ftruncate: OK
....
```
I attached the log-file.[test-suite.log](/uploads/617a2b629fb6d6dba44040165fc9ac7e/test-suite.log)Tor: 0.4.5.x-post-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/40318tor-0.4.5.6: NetBSD test failures2021-04-08T11:30:05Zwiztor-0.4.5.6: NetBSD test failuresWhen running the self tests for tor-0.4.5.6 on NetBSD-9.99.80/amd64, I see a few failures.
gmake && gmake check gives me:
```
/usr/pkg/bin/gmake check-TESTS check-local
gmake[1]: Entering directory '/scratch/net/tor/work/tor-0.4.5.6'
...When running the self tests for tor-0.4.5.6 on NetBSD-9.99.80/amd64, I see a few failures.
gmake && gmake check gives me:
```
/usr/pkg/bin/gmake check-TESTS check-local
gmake[1]: Entering directory '/scratch/net/tor/work/tor-0.4.5.6'
gmake[2]: Entering directory '/scratch/net/tor/work/tor-0.4.5.6'
PASS: src/test/test-slow
PASS: src/test/test-memwipe
PASS: src/test/test_workqueue
PASS: src/test/test_keygen.sh
PASS: src/test/test_key_expiration.sh
PASS: src/test/test-timers
SKIP: src/test/fuzz_static_testcases.sh
PASS: src/test/test_zero_length_keys.sh
PASS: src/test/test_workqueue_cancel.sh
SKIP: src/test/test_workqueue_efd.sh
SKIP: src/test/test_workqueue_efd2.sh
PASS: src/test/test_workqueue_pipe.sh
PASS: src/test/test_workqueue_pipe2.sh
PASS: src/test/test_workqueue_socketpair.sh
SKIP: src/test/test_switch_id.sh
PASS: src/test/test_cmdline.sh
PASS: src/test/test_parseconf.sh
PASS: src/test/unittest_part1.sh
FAIL: src/test/unittest_part2.sh
PASS: src/test/unittest_part3.sh
PASS: src/test/unittest_part4.sh
PASS: src/test/unittest_part5.sh
PASS: src/test/unittest_part6.sh
PASS: src/test/unittest_part7.sh
FAIL: src/test/unittest_part8.sh
PASS: src/test/test_ntor.sh
PASS: src/test/test_hs_ntor.sh
PASS: src/test/test_bt.sh
PASS: scripts/maint/practracker/test_practracker.sh
PASS: scripts/maint/run_check_subsystem_order.sh
PASS: src/test/test_rebind.sh
FAIL: src/test/test_include.sh
PASS: scripts/maint/checkSpaceTest.sh
============================================================================
Testsuite summary for tor 0.4.5.6
============================================================================
# TOTAL: 33
# PASS: 26
# SKIP: 4
# XFAIL: 0
# FAIL: 3
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
============================================================================
```
The test-suite.log file is quite big, I'll attach it.
Nick Mathewson wrote:
Looks like a bug in the new wildcard handling for
configuration-file includes:
```
config/include_wildcards:
FAIL src/test/test_config.c:6113:
assert(config_get_lines_include(torrc_contents, &result, 0,
&include_used, NULL) OP_EQ 0): -1 vs 0
[include_wildcards FAILED]
config/include_opened_file_list:
FAIL src/test/test_config.c:6502:
assert(config_get_lines_include(torrc_contents, &result, 0,
&include_used, opened_files) OP_EQ 0): -1 vs 0
[include_opened_file_list FAILED]
```
[test-suite.log](/uploads/e4b686d3704d0ac895e043f899118b8b/test-suite.log)Tor: 0.4.5.x-post-stableGeorge KadianakisGeorge Kadianakishttps://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/40304TROVE-2021-001: Bug in dump_desc() code2021-03-19T17:20:17ZNick MathewsonTROVE-2021-001: Bug in dump_desc() codeThe dump_desc() code dumps its entire input, but it is sometimes called with an input that extends beyond the end of the string.
This can cause two kinds of bugs:
* A CPU-based DOS bug, where we try to parse a string that contains a ...The dump_desc() code dumps its entire input, but it is sometimes called with an input that extends beyond the end of the string.
This can cause two kinds of bugs:
* A CPU-based DOS bug, where we try to parse a string that contains a zillion tiny unparseable descriptors.
* Possibly, an unbounded read bug, where we read off the end of an allocation. The latter is not a privacy leak, since we don't expose the data, but it could be a crash bug. (I think it might not even be a crash bug, since we NUL-terminate our downloads, but we should check.)
For 0.3.5 through 0.4.4, I believe we should just disable dump_desc().
For a real fix, we should give it a length argument.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40298Non-portable `test ==` used in configure.ac2021-02-17T18:23:13ZNick MathewsonNon-portable `test ==` used in configure.ac```
configure.ac: if test "$ac_retval" == "1"; then
```
This isn't portable. Reported by Thomas Klausner.```
configure.ac: if test "$ac_retval" == "1"; then
```
This isn't portable. Reported by Thomas Klausner.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewson