Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-07-07T00:47:10Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40434Don't set router is_running=false after intentionally closing a directory con...2022-07-07T00:47:10ZoparaDon't set router is_running=false after intentionally closing a directory connectionIn a testing tor network with a few relays, clients, and an onion service, the onion service will call `run_upload_descriptor_event()` periodically to upload its service descriptor. This eventually calls `directory_initiate_request()` wh...In a testing tor network with a few relays, clients, and an onion service, the onion service will call `run_upload_descriptor_event()` periodically to upload its service descriptor. This eventually calls `directory_initiate_request()` which creates a new dir connection for the upload. In the future when `run_upload_descriptor_event()` runs again, it will first call `close_directory_connections()` to mark for close any existing/incomplete descriptor uploads for that service. Later (on the next 1 second libevent timer) the dir connection will be closed and since the upload didn't finish, `connection_dir_client_request_failed()` will set the router's `is_running` field to false.
The problem is that `run_upload_descriptor_event()` can run shortly after a previous run, and in a shadow simulation, this can run only 2 seconds after a previous run. If the descriptor upload has not finished in this 2 seconds, the router will be marked as not running and will not be added to the routerlist when building circuits. Since this dir client request can fail often due to tor's new circuit timeout learning, in small tor networks we quickly run out of nodes in the routerlist, and end up with:
```
Jan 01 00:17:50.000 [info] compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as middle node
Jan 01 00:17:50.000 [info] router_choose_random_node(): We couldn't find any live, stable routers; falling back to list of all routers.
Jan 01 00:17:50.000 [info] compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as middle node
Jan 01 00:17:50.000 [warn] No available nodes when trying to choose node. Failing.
Jan 01 00:17:50.000 [info] pick_needed_intro_points(): Unable to find a suitable node to be an introduction point for service r4aj4kaqf46mala2yykldkvwrrwjagab2qppuqtvgdxwh6spsulwu2qd.
```
I propose to not mark a router as "not running" if tor intentionally closes a directory connection (except maybe for a `TestingDirConnectionMaxStall` timeout).Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34083Client rendezvous circuit is no longer in circuit_wait but in pending_entry_c...2021-10-08T14:44:40Zs7rClient rendezvous circuit is no longer in circuit_wait but in pending_entry_connectionsWhen you are creating many rendezvous client circuits with a reasonable concurrency, you get tons of messages in the log file marked as bug like this:
```
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877d94940 is...When you are creating many rendezvous client circuits with a reasonable concurrency, you get tons of messages in the log file marked as bug like this:
```
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877d94940 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d8789c16c0 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d875eef5a0 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d876063640 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877b92960 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d8764ae550 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d878a83f00 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877854530 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d878cac3a0 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d875b8d290 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d8788a4d70 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d878144a30 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877a2dc30 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
```
No sense to send more lines since they are all the same, but just with different circuit ID. The number of such messages exceeds 1000 in a total say at least 100.000 built rendezvous circuits.Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34303Find out why onion service measurements have gotten slower2022-07-07T00:49:01ZKarsten LoesingFind out why onion service measurements have gotten slowerToday I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torp...Today I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torproject.org/torperf.html?start=2020-02-25&end=2020-05-25&server=onion&filesize=50kb) and found that the onion service measurements made by op-nl2, op-us2, and op-hk2 have gotten much slower as compared to their op-nl, op-us, and op-hk predecessors.
I'm 95% certain that this is not a bug in the graphs.
My current best guess is that something in `tor` has changed. I'd like to set up a small number of experimental OnionPerf instances all in the same place but with different `tor` versions. Any suggestions on locations (Amsterdam, Florida, Hong Kong) or `tor` versions?
This is also relevant to Sponsor 59 in order to make sure that our current measurements are going to be a baseline for future experiments. Classifying as potential defect.Tor: 0.3.5.x-finalKarsten LoesingKarsten Loesinghttps://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/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/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/33212Warning in protover.rs making CI fail.2020-06-27T13:48:20ZNick MathewsonWarning in protover.rs making CI fail.It looks like a new version of Rust is warning about extraneous parentheses, causing our CI to fail in some cases. Let's fix that.
(This is possibly a duplicate, but I can't find the original.)It looks like a new version of Rust is warning about extraneous parentheses, causing our CI to fail in some cases. Let's fix that.
(This is possibly a duplicate, but I can't find the original.)Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33131Bug: buf->datalen >= 0x7fffffff2021-01-28T18:01:38ZcypherpunksBug: buf->datalen >= 0x7fffffffWith
```
BandwidthRate
```
set greater than 2147483646 bytes, for example Config line:
```
BandwidthRate 2147483647
#same as
BandwidthRate 2 GBytes
```
no streams complete in my relay and this Bug message appears:
```
Feb 02 06:...With
```
BandwidthRate
```
set greater than 2147483646 bytes, for example Config line:
```
BandwidthRate 2147483647
#same as
BandwidthRate 2 GBytes
```
no streams complete in my relay and this Bug message appears:
```
Feb 02 06:32:37.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(ASSERT_PREDICT
_UNLIKELY_(buf->datalen >= 0x7fffffff - at_most)) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.5 )
Feb 02 06:32:37.000 [warn] {BUG} Bug: Tor 0.4.2.5: Non-fatal assertion !(ASSERT_PREDICT_UNLIKELY_(buf->datalen >= 0x7fffffff - at_mo
st)) failed in buf_read_from_tls at buffers_tls.c:73. (Stack trace not available) (on Tor 0.4.2.5 )
```
Looks like some INT_MAX buffer count trouble to me at least.
```
# BandwidthRate BandwidthRate __N__ bytes|KBytes|MBytes|GBytes|TBytes|KBits|MBits|GBits|TBits
# A token bucket limits the average incoming bandwidth usage on this node
# to the specified number of bytes per second, and the average outgoing
# bandwidth usage to that same value. If you want to run a relay in the
# public network, this needs to be _at the very least_ 75 KBytes for a
# relay (that is, 600 kbits) or 50 KBytes for a bridge (400 kbits) -- but of
# course, more is better; we recommend at least 250 KBytes (2 mbits) if
# possible. (Default: 1 GByte) +
# +
# Note that this option, and other bandwidth-limiting options, apply to TCP
# data only: They do not count TCP headers or DNS traffic. +
# +
# With this option, and in other options that take arguments in bytes,
# KBytes, and so on, other formats are also supported. Notably, "KBytes" can
# also be written as "kilobytes" or "kb"; "MBytes" can be written as
# "megabytes" or "MB"; "kbits" can be written as "kilobits"; and so forth.
# Tor also accepts "byte" and "bit" in the singular.
# The prefixes "tera" and "T" are also recognized.
# If no units are given, we default to bytes.
# To avoid confusion, we recommend writing "bytes" or "bits" explicitly,
# since it's easy to forget that "B" means bytes, not bits.
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32449Appveyor: OpenSSL version mismatch in unit tests, 2019 edition2020-06-27T13:48:52ZteorAppveyor: OpenSSL version mismatch in unit tests, 2019 edition```
crypto/openssl_version: [forking]
FAIL ../src/test/test_crypto.c:237: OpenSSL library version 1.1.1d did not begin with header version 1.1.1c.
[openssl_version FAILED]
```
https://ci.appveyor.com/project/torproject/tor/builds/28...```
crypto/openssl_version: [forking]
FAIL ../src/test/test_crypto.c:237: OpenSSL library version 1.1.1d did not begin with header version 1.1.1c.
[openssl_version FAILED]
```
https://ci.appveyor.com/project/torproject/tor/builds/28757237/job/ul9m0fnglaqtw3oy?fullLog=true#L3511Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32407Fix crash when calling --dump-config with failing set_options2020-06-27T13:48:53ZNick MathewsonFix crash when calling --dump-config with failing set_optionsIt appears that our cleanup code hits an assertion failure when we have been called with --dump-config and a set of options that fails in set_options().It appears that our cleanup code hits an assertion failure when we have been called with --dump-config and a set of options that fails in set_options().Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32058mainloop: make periodic events restartable2020-07-14T22:24:09Zteormainloop: make periodic events restartableWhen we shut down tor, we disable periodic events, but leave their enabled flag set to 1.
See this PR for details:
https://github.com/torproject/tor/pull/1397
I'm not sure if this is the best solution, or how far we should backport.When we shut down tor, we disable periodic events, but leave their enabled flag set to 1.
See this PR for details:
https://github.com/torproject/tor/pull/1397
I'm not sure if this is the best solution, or how far we should backport.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31939log spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf...2020-07-14T22:24:13ZTaylor Yulog spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT_MAX - at_most) failed.Nonfatal assert log spamming as seen in legacy/trac#31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0....Nonfatal assert log spamming as seen in legacy/trac#31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0.4.0.5 )
```
(I assume the `#` in the middle of `INT_MAX` is a paste/transcription artifact, but then again it might not be.)Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31884Define ExecuteBash in the Appveyor error block2020-07-14T22:24:01ZteorDefine ExecuteBash in the Appveyor error blockWhen Appveyor fails before ExecuteBash is defined, it skips straight to the error block. But the error block wants ExecuteBash. So we should define it twice.
Example:
https://ci.appveyor.com/project/nmathewson/tor/build/1.0.850/job/v5mw...When Appveyor fails before ExecuteBash is defined, it skips straight to the error block. But the error block wants ExecuteBash. So we should define it twice.
Example:
https://ci.appveyor.com/project/nmathewson/tor/build/1.0.850/job/v5mws73je9sihmfnTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31837Make test_rebind.py more robust2020-07-14T22:24:20ZteorMake test_rebind.py more robust* actually sleep when waiting for tor to log
* log at debug level when waiting for tor to log
* backslash-replace bad UTF-8 characters in logs
* format control commands as ASCII, tor does not accept UTF-8 control commands
Found during l...* actually sleep when waiting for tor to log
* log at debug level when waiting for tor to log
* backslash-replace bad UTF-8 characters in logs
* format control commands as ASCII, tor does not accept UTF-8 control commands
Found during legacy/trac#30901.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31571Add the tor version and a newline to raw_assert()2020-07-14T22:24:18ZteorAdd the tor version and a newline to raw_assert()We're missing a newline and the tor version in the logs for legacy/trac#31570.We're missing a newline and the tor version in the logs for legacy/trac#31570.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31548hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro po...2021-06-23T17:24:15ZDavid Gouletdgoulet@torproject.orghs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro pointsDuring my testing of legacy/trac#30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_i...During my testing of legacy/trac#30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_intro_points()` function which showed me 4 intro points.
I haven't found out why but one feature of HS is that we launch `HiddenServiceNumIntroductionPoints` + 2 intro circuits in parallel and the first one to finish are picked.
It appears that more than the defined value can finish at the same time and will be picked.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31408torrc : ClientOnionAuthDir after include directives breaks client to v2 services2021-06-23T17:24:15ZTractorrc : ClientOnionAuthDir after include directives breaks client to v2 servicesIf I append these two statements to torrc, in this order :
ClientOnionAuthDir /etc/tor/auth/
%include /etc/tor/torrc.d/
and restart tor.service, I can connect to 1 × v3 and 4 × v2 services, within seconds.
But if I reverse their order...If I append these two statements to torrc, in this order :
ClientOnionAuthDir /etc/tor/auth/
%include /etc/tor/torrc.d/
and restart tor.service, I can connect to 1 × v3 and 4 × v2 services, within seconds.
But if I reverse their order ( %include first ), I can only connect to the v3 service -- all other connections will eventually time out.
In man, I missed to find any recommandation about ordering these statements.
( this is on Debian Stretch with torproject's stretch repo )
Thanks!
**Trac**:
**Username**: xahoTor: 0.3.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/31008Typographical error on tor man pages help command2020-06-29T15:24:29ZAadi BajpaiTypographical error on tor man pages help commandman tor gives the following output as the first command:
```
-h, -help
Display a short help message and exit.
```
Except it's --help and not -help.
-help doesn't work, I found it weird so I tested it just in case and it doesn't.
New ...man tor gives the following output as the first command:
```
-h, -help
Display a short help message and exit.
```
Except it's --help and not -help.
-help doesn't work, I found it weird so I tested it just in case and it doesn't.
New users may get confused if they don't know the -h/--help convention.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30916assert in dimap_add_entry()2020-07-14T22:24:14ZDavid Gouletdgoulet@torproject.orgassert in dimap_add_entry()From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "defau...From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "default"
============================================================ T= 1560854012
INTERNAL ERROR: Raw assertion failed at ../src/lib/ctime/di_ops.c:179: !
old_val/usr/bin/tor(dump_stack_symbols_to_error_fds+0x33)[0x55a17b410943]
/usr/bin/tor(tor_raw_assertion_failed_msg_+0x86)[0x55a17b410fd6]
/usr/bin/tor(dimap_add_entry+0xa0)[0x55a17b411ba0]
/usr/bin/tor(construct_ntor_key_map+0x69)[0x55a17b357969]
/usr/bin/tor(server_onion_keys_new+0x4d)[0x55a17b39f4dd]
/usr/bin/tor(+0x66e27)[0x55a17b287e27]
/usr/bin/tor(threadpool_new+0x18b)[0x55a17b3b3f0b]
/usr/bin/tor(cpu_init+0x9d)[0x55a17b28828d]
/usr/bin/tor(run_tor_main_loop+0x136)[0x55a17b27a496]
/usr/bin/tor(tor_run_main+0x1215)[0x55a17b27b935]
/usr/bin/tor(tor_main+0x3a)[0x55a17b278a8a]
/usr/bin/tor(main+0x19)[0x55a17b278609]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7ffb901ba2e1]
/usr/bin/tor(_start+0x2a)[0x55a17b27865a]
Jun 18 13:33:33.000 [notice] Tor 0.3.5.8 opening log file.
```
It appears that tor tried to add the same value in the `di_digest256_map_t` twice.
Logs indicate 0.3.5.8Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30744Allow failures in the Travis test-stem job2020-06-27T13:50:06ZteorAllow failures in the Travis test-stem jobTor: 0.3.5.x-finalteorteor