Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-07-07T00:48:31Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40124Incorrect key ID type used in some ed25519 certificates2022-07-07T00:48:31ZNick MathewsonIncorrect key ID type used in some ed25519 certificatesIn `cert-spec.txt` we specify several possible values for the CERT_KEY_TYPE field, in section A.4. But we don't actually use those: everywhere that we call `tor_cert_sign_impl()` , signed_key type is set to `SIGNED_KEY_TYPE_ED25519`.
...In `cert-spec.txt` we specify several possible values for the CERT_KEY_TYPE field, in section A.4. But we don't actually use those: everywhere that we call `tor_cert_sign_impl()` , signed_key type is set to `SIGNED_KEY_TYPE_ED25519`.
We should adjust the spec to clarify that current tor implementations behave, and (assuming it won't introduce compatibility issue) adjust Tor relay behavior to conform to the spec. We should probably leave onion service behavior alone.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40076Assertion buf->tail failed in buf_assert_ok at src/lib/buf/buffers.c:9192021-02-05T21:03:36ZDimitris ApostolouAssertion buf->tail failed in buf_assert_ok at src/lib/buf/buffers.c:919Latest master on macOS 10.15.6
```
Jul 30 09:50:12.000 [notice] Bootstrapped 100% (done): Done
Jul 30 09:50:13.000 [err] tor_assertion_failed_: Bug: src/lib/buf/buffers.c:919: buf_assert_ok: Assertion buf->tail failed; aborting. (on Tor...Latest master on macOS 10.15.6
```
Jul 30 09:50:12.000 [notice] Bootstrapped 100% (done): Done
Jul 30 09:50:13.000 [err] tor_assertion_failed_: Bug: src/lib/buf/buffers.c:919: buf_assert_ok: Assertion buf->tail failed; aborting. (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: Tor 0.4.5.0-alpha-dev (git-9164d7c75e619182): Assertion buf->tail failed in buf_assert_ok at src/lib/buf/buffers.c:919: . Stack trace: (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 0 tor 0x000000010c69dbd9 log_backtrace_impl + 89 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 1 tor 0x000000010c699a92 tor_assertion_failed_ + 322 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 2 tor 0x000000010c675d6f buf_assert_ok + 495 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 3 tor 0x000000010c4e3d7c assert_connection_ok + 220 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 4 tor 0x000000010c4eecc6 conn_read_callback + 326 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 5 libevent-2.1.7.dylib 0x000000010ca0bfde event_process_active_single_queue + 1186 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 6 libevent-2.1.7.dylib 0x000000010ca08ddb event_base_loop + 1174 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 7 tor 0x000000010c4f1115 do_main_loop + 309 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 8 tor 0x000000010c623be8 tor_run_main + 296 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 9 tor 0x000000010c542f1d tor_main + 125 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 10 tor 0x000000010c4de01b main + 27 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 11 libdyld.dylib 0x00007fff67dd5cc9 start + 1 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
```Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40073Bug: Tor 0.4.4.3-alpha: Assertion new_conn failed in retry_all_listeners at s...2022-07-07T00:48:30ZtoralfBug: Tor 0.4.4.3-alpha: Assertion new_conn failed in retry_all_listeners at src/core/mainloop/connection.c:3047I changed the torrc from
```
DirPort 80
ORPort 443
```
to
```
DirPort 5.9.158.75:80
ORPort 5.9.158.75:443
```
and runa "rc-service tor reload" hera at a hardened stable Gentoo Linux with sandboxing and got a
```
Jul 28 20:30:52.000 [n...I changed the torrc from
```
DirPort 80
ORPort 443
```
to
```
DirPort 5.9.158.75:80
ORPort 5.9.158.75:443
```
and runa "rc-service tor reload" hera at a hardened stable Gentoo Linux with sandboxing and got a
```
Jul 28 20:30:52.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jul 28 20:30:52.000 [notice] Read configuration file "/etc/tor/torrc".
Jul 28 20:30:52.000 [notice] Processing configuration path "/etc/tor/torrc.d/" at recursion level 1.
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//00_common".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//20_exit_flag".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//40_reject".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//80_accept".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//90_reject_all".
Jul 28 20:30:52.000 [notice] Opening Directory listener on 5.9.158.75:80
Jul 28 20:30:52.000 [warn] Could not bind to 5.9.158.75:80: Permission denied
Jul 28 20:30:52.000 [err] tor_assertion_failed_(): Bug: src/core/mainloop/connection.c:3047: retry_all_listeners: Assertion new_conn failed; aborting. (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: Tor 0.4.4.3-alpha: Assertion new_conn failed in retry_all_listeners at src/core/mainloop/connection.c:3047: . Stack trace: (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(log_backtrace_impl+0x59) [0x557166a32c19] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x150) [0x557166a2de10] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(retry_all_listeners+0x671) [0x55716689fac1] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(set_options+0xa48) [0x5571669ab908] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(+0x1776a0) [0x5571669ac6a0] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(options_init_from_string+0x119) [0x5571669ac8f9] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(options_init_from_torrc+0x372) [0x5571669acf12] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(+0x5d444) [0x557166892444] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/lib64/libevent-2.1.so.7(+0x21c86) [0x7f7a42484c86] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/lib64/libevent-2.1.so.7(event_base_loop+0x57f) [0x7f7a4248596f] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(do_main_loop+0xdd) [0x5571668a728d] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(tor_run_main+0x855) [0x557166893fa5] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(tor_main+0x46) [0x557166892176] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(main+0x19) [0x557166891d49] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7f7a41d26e2b] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(_start+0x2a) [0x557166891d9a] (on Tor 0.4.4.3-alpha )
```
Tor should IMO reject the config change in such a case, or?Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40034resolved_addr_set_suggested() cannot succeed2022-07-07T00:48:30ZNick Mathewsonresolved_addr_set_suggested() cannot succeedThis code will always trigger the BUG:
```
if (BUG(tor_addr_family(addr) != AF_INET ||
tor_addr_family(addr) != AF_INET6)) {
return;
}
```
Maybe this should be `&&`, not `||`?
Possibly related to #40032, possibly not....This code will always trigger the BUG:
```
if (BUG(tor_addr_family(addr) != AF_INET ||
tor_addr_family(addr) != AF_INET6)) {
return;
}
```
Maybe this should be `&&`, not `||`?
Possibly related to #40032, possibly not.
Found via a compiler warning on travis.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33768Make tor_inet_pton() handle bad addresses consistently on Windows2020-07-09T17:42:27ZteorMake tor_inet_pton() handle bad addresses consistently on Windowstor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/p...tor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/pull/1831/commits/05f4f93722d46c0e8f1d09b4dea4bf5d1743d93f#diff-048243cd6d9ed36dda0944181d8ec8abR1729
Let's fix this bug and backport it.
In general, we should make all the functions in this file behave identically:
* zero any out parameters at the start of the function
* zero any out parameters on failureTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33437Unsuccessful compilation of tor on FreeBSD system with libssl.so.112020-09-23T13:43:20ZTracUnsuccessful compilation of tor on FreeBSD system with libssl.so.11+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files a...+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files are attached.
Notes:
- compilation of **0.4.2.6** with **libssl.so.9** was successful
- compilation of **0.4.2.6** with **libssl.so.11** was unsuccessful
----
**Trac**:
**Username**: stillicideTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33409Pre-commit hook does not stash unstaged changes before running code style che...2020-07-29T14:34:18Zrl1987Pre-commit hook does not stash unstaged changes before running code style checkersHow to reproduce:
1) Make some changes to C files and violate whitespace rules.
2) `git add` affected files and try to `git commit`. Pre-commit hook will not allow it and will print the whitespace issues it found.
3) Fix whitespace prob...How to reproduce:
1) Make some changes to C files and violate whitespace rules.
2) `git add` affected files and try to `git commit`. Pre-commit hook will not allow it and will print the whitespace issues it found.
3) Fix whitespace problems, but forget to `git add` the files.
4) Running `git commit` again does not reject the changes, despite whitespace fixes not being staged. New commit now includes whitespace violations and none of the fixes that were done in step 3.
This is not limited to whitespace issues, but could affect other code style checks as well.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33237Prop 312: 3.2.2. Stop Directory Authorities Resolving *Port Hostnames2021-08-23T15:12:44ZteorProp 312: 3.2.2. Stop Directory Authorities Resolving *Port HostnamesFor security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort an...For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort and DirPort options.
As part of this fix, we may also ban DNS resolution on all configured Ports. (We should try to avoid banning DNS resolution entirely on authorities, because some test networks use Authority/Exits.)
See proposal 312, section 3.2.2, directory authority case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n340
Directory authorities must not attempt to resolve these
addresses using DNS. It is a config error to provide a hostname as a
directory authority's ORPort or DirPort.
If directory authorities don't have an IPv4 address literal in their
Address or ORPort, they should issue a configuration error, and refuse to
launch. If directory authorities don't have an IPv6 address literal in their
Address or ORPort, they should issue a notice-level log, and fall back to
only using IPv4.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/32349hs-v2: Intro point circuit TIMEOUT failure is not reported2021-06-23T17:23:06ZDavid Gouletdgoulet@torproject.orghs-v2: Intro point circuit TIMEOUT failure is not reportedThis was found while I was working on legacy/trac#32020.
For v2, we report a TIMEOUT circuit failure within `circuit_about_to_free()`. The following code is the snippet on how we check if the circuit timed out:
```
int reason = circ->m...This was found while I was working on legacy/trac#32020.
For v2, we report a TIMEOUT circuit failure within `circuit_about_to_free()`. The following code is the snippet on how we check if the circuit timed out:
```
int reason = circ->marked_for_close_reason;
int timed_out = (reason == END_CIRC_REASON_TIMEOUT);
```
However, in `circuit_mark_for_close_()`, if the circuit is an origin one, which is the case for all HS client circuit, the `marked_for_close_reason` is set to `END_CIRC_REASON_NONE` so we don't send back that reason back within the destroy cell.
The fix is that we should be looking at `marked_for_close_orig_reason` instead.
We need to backport this.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31565static Tor building against openssl-1.1.1 fails: configure unable to find lin...2020-07-29T13:10:29ZTracstatic Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSLTrying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4...Trying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4.0.5 and 0.4.1.5. Building against openssl-1.0.2 works.
**Trac**:
**Username**: shredderTor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/25061Relays log a bootstrap warning if they can't extend for somebody else's circuit2020-10-20T10:28:37ZRoger DingledineRelays log a bootstrap warning if they can't extend for somebody else's circuitSay you have a relay that is up and listed as non-slow in the consensus. Due to the current overload (legacy/trac#24902), this relay is getting many many circuit requests per second. Due to bug legacy/trac#24767, we will make a huge numb...Say you have a relay that is up and listed as non-slow in the consensus. Due to the current overload (legacy/trac#24902), this relay is getting many many circuit requests per second. Due to bug legacy/trac#24767, we will make a huge number of connection attempts to other relays that are down, because as soon as we get a "connection refused", we will get another circuit request that triggers another connection attempt.
So when your relay restarts, since it's still in the consensus and clients still think it's usable, it will immediately get flooded with circuit requests, causing these connection attempts to resume.
And Tor calls every one of those connection attempts a bootstrapping attempt, even if there are no origin circuits related to that connection attempt.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22881Unreachable relays launch multiple testing circuits per second2021-09-16T14:31:59ZteorUnreachable relays launch multiple testing circuits per secondWhen I start a relay behind a NAT with:
```
tor ORPort 12345 PublishServerDescriptor 0 Log "info stderr"
```
I see it launch multiple testing circuits every second.
This places a lot of load on the network: it should use exponential bac...When I start a relay behind a NAT with:
```
tor ORPort 12345 PublishServerDescriptor 0 Log "info stderr"
```
I see it launch multiple testing circuits every second.
This places a lot of load on the network: it should use exponential backoff instead.
We wanted to fix things like this as part of legacy/trac#4580 or legacy/trac#8625, but it seems we missed this case. Maybe we need to do exponential backoff at a lower level than directory requests?
Here are the log messages for one second:
```
Jul 11 19:07:20.000 [info] circuit_finish_handshake: Finished building circuit hop:
Jul 11 19:07:20.000 [info] internal circ (length 3, last hop Unnamed): $3E13E2EB87CCF5690564EE33E9F9F9F80B229FBB(open) $34D2E3C853C6C60A5CCD93E363CD524BA962D3D6(open) $4345CA43B1F4E1C08271F8FA907B4AE890591111(closed)
Jul 11 19:07:20.000 [info] circuit_send_next_onion_skin: Sending extend relay cell.
Jul 11 19:07:20.000 [info] consider_testing_reachability: Testing reachability of my ORPort: 124.171.199.202:12345.
Jul 11 19:07:20.000 [info] onion_pick_cpath_exit: Using requested exit node '$4345CA43B1F4E1C08271F8FA907B4AE890591111~Unnamed at 124.171.199.202'
Jul 11 19:07:20.000 [info] extend_info_from_node: Not including the ed25519 ID for $7202A9449EC084A305EB19A2A2A0E245FA8C111E~jonasBebe2 at 193.200.241.195, since it won't be able to authenticate it.
Jul 11 19:07:20.000 [info] extend_info_from_node: Not including the ed25519 ID for $CA618B8FB8FDF1C670BA7139B1E3EFCE25771551~bentleywashere3 at 198.199.90.205, since it won't be able to authenticate it.
Jul 11 19:07:20.000 [info] circuit_handle_first_hop: Next router is [scrubbed]: Not connected. Connecting.
Jul 11 19:07:20.000 [info] connection_or_set_identity_digest: Set identity digest for 0x7fcefb6f1cd0 ([scrubbed]): 7202A9449EC084A305EB19A2A2A0E245FA8C111E <unset>.
Jul 11 19:07:20.000 [info] connection_or_set_identity_digest: (Previously: 0000000000000000000000000000000000000000 <unset>)
Jul 11 19:07:20.000 [info] channel_tls_process_versions_cell: Negotiated version 4 with [scrubbed]:443; Sending cells: CERTS
Jul 11 19:07:20.000 [info] connection_or_client_learned_peer_id: learned peer id for 0x7fcefaf87090 ([scrubbed]): 650ABAB06345EEC29BB0B5322C27DC6E5E888019, <null>
Jul 11 19:07:20.000 [info] channel_tls_process_certs_cell: Got some good certificates from [scrubbed]:443: Authenticated it with RSA
Jul 11 19:07:20.000 [info] channel_tls_process_auth_challenge_cell: Got an AUTH_CHALLENGE cell from [scrubbed]:443: Sending authentication type 1
Jul 11 19:07:20.000 [info] circuit_send_next_onion_skin: First hop: finished sending CREATE cell to '$650ABAB06345EEC29BB0B5322C27DC6E5E888019~supc0re at 217.160.15.198'
Jul 11 19:07:20.000 [info] channel_tls_process_netinfo_cell: Got good NETINFO cell from [scrubbed]:443; OR connection is now open, using protocol version 4. Its ID digest is 650ABAB06345EEC29BB0B5322C27DC6E5E888019. Our address is apparently 124.171.199.202.
Jul 11 19:07:20.000 [info] circuit_expire_building: Abandoning circ 198 37.187.3.106:443:3622949943 (state 0,0:doing handshakes, purpose 18, len 3)
Jul 11 19:07:20.000 [info] internal circ (length 3, last hop Unnamed): $597422ADDADAF5FB2727369B7EFC7AA76B89D613(open) $E7578F3484C8ABD5FB3130E31F30C167206BCA7E(open) $4345CA43B1F4E1C08271F8FA907B4AE890591111(waiting for keys)
Jul 11 19:07:20.000 [info] circuit_testing_failed: Our testing circuit (to see if your ORPort is reachable) has failed. I'll try again later.
Jul 11 19:07:20.000 [info] circuit_finish_handshake: Finished building circuit hop:
Jul 11 19:07:20.000 [info] internal circ (length 3, last hop Unnamed): $650ABAB06345EEC29BB0B5322C27DC6E5E888019(open) $45D6A70CAEC4A2C2FCE46A127E461FF852A41280(closed) $4345CA43B1F4E1C08271F8FA907B4AE890591111(closed)
Jul 11 19:07:20.000 [info] circuit_send_next_onion_skin: Sending extend relay cell.
```Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21044ORPort self reachability test happens also when it shouldn't2020-08-06T14:38:06Zs7rORPort self reachability test happens also when it shouldn'tI think we did not cover all cases when the self reachability test before publishing descriptors was introduced.
I am running a bridge with `PublishServerDescriptor 0` and `ORPort 127.0.0.1:443` because I want to run it just to do some...I think we did not cover all cases when the self reachability test before publishing descriptors was introduced.
I am running a bridge with `PublishServerDescriptor 0` and `ORPort 127.0.0.1:443` because I want to run it just to do some responsible testing without hammering the public Guards used by other clients. The bridge is configured with `PublishServerDescriptor 0` so it means I don't need a descriptor, I don't intend to make the bridge (or relay) public.
When a bridge is run in the conditions described above the log is spammed (exactly one log message at every 20 minutes) with:
```
[warn] Your server (PUBLIC_IP:443) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
```
and
```
[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address PUBLIC_IP. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
```
What it did wrong:
- It guessed the public IP address and tried to make the self test on that address, regardless it's not the address explicitly configured at `ORPort`. `Address` is not set in this setup.
- Based on the second log message, I think it even overwritten the address used with `ORPort` with the public IP address that it guessed and built the descriptor.
- It infinitely tries once every 20 minutes and logs a message that the descriptor cannot be published (and my intention based on the options configured is exactly not to publish one even if the tests were successful).
What Tor should do:
- Bypass the protocol to guess `Address` (the public IP address) when `ORPort` / `DirPort` is explicitly configured as a loopback address or NAT address. This will have a logic follow-up (which I think we already do, but want to make sure) like this:
- Bypass self tests when `ORPort` / `DirPort` address is explicitly configured as a loopback address or NAT address (simplest thing would be to treat these cases as like `AssumeReachable 1` is set). Such addresses cannot be tested from the public internet anyway.
- `PublishServerDescriptor 0` maybe should not even build a descriptor at all, or at least bypass the self tests in this case too, it does not make sense to try to test something we never want to publish. Or, only make 1 attempt to test and log a message stating success or failure.
legacy/trac#19919 is kind of related, it treats as it should the cases where `ORPort` is explicitly configured as a public address. In this ticket we cover an extension for cases where `ORPort` is a loopback or NAT address.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20165When a relay advertises a new, unreachable address, OR reachability can succe...2023-05-12T18:28:13ZteorWhen a relay advertises a new, unreachable address, OR reachability can succeed via the old addressIf a relay has advertised a reachable address in the past, and continues listening on the old address, clients and relays will continue to contact Tor on that address for a few hours.
If the relay starts advertising a new, unreachable a...If a relay has advertised a reachable address in the past, and continues listening on the old address, clients and relays will continue to contact Tor on that address for a few hours.
If the relay starts advertising a new, unreachable address, ORPort reachability will appear to succeed for that new address, because Tor doesn't (and probably can't) check the address clients are connecting to is the one it actually advertised.
And Tor doesn't do ongoing reachability checks, so it publishes its descriptor based on the mistaken reachability, and assumes everthing is OK from then on.
Fortunately, the mandatory DirPort check catches this in 0.2.8 and later.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19431ratelimit message is incorrect.2020-08-25T12:02:43ZNick Mathewsonratelimit message is incorrect.In 5c596cdbc086698c52 I added an XXXX comment to rate_limit_log.
When we say "100 messages suppressed in the last 3600 seconds", we're not being accurate. Those messages were suppressed over a period of time at the start of which the l...In 5c596cdbc086698c52 I added an XXXX comment to rate_limit_log.
When we say "100 messages suppressed in the last 3600 seconds", we're not being accurate. Those messages were suppressed over a period of time at the start of which the last message of this type was logged, and ending some time before the present... but they could have occurred days ago, or all 1 second ago.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5304Obfsproxy should respect OutboundBindAddress in torrc2020-10-15T16:30:29ZTracObfsproxy should respect OutboundBindAddress in torrcRather it just binds to * (any IP).
Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.
**Trac**:
**Username**: korobkovRather it just binds to * (any IP).
Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.
**Trac**:
**Username**: korobkovTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/2178We launch dummy descriptor fetches more often than needed2020-09-22T15:11:40ZNick MathewsonWe launch dummy descriptor fetches more often than neededRight now, we have code in update_router_descriptor_downloads() to launch a fetch for authority.z if we want to learn our IP from a directory fetch. We do this if:
* We're a server
* We don't have the Address option set
* At le...Right now, we have code in update_router_descriptor_downloads() to launch a fetch for authority.z if we want to learn our IP from a directory fetch. We do this if:
* We're a server
* We don't have the Address option set
* At least 20 minutes have passed since we last launched a router descriptor download
* At least 20 minutes have passed since we last launched a
Per discussion in bug legacy/trac#652, we could be even more quiet about launching these fetches. We could also require that
* At least 20 minutes have passed since we last launched *any* appropriate directory op.
* At least 20 minutes have passed since we got a new incoming connection on what we think our IP is.
* At least 20 minutes have passed since we got confirmation of our current IP in a NETINFO cell
We could also make the "20 minutes" value configurable by a networkstatus parameter.
This is a minor issue, since the current behavior is inelegant, but not actually hurting anything.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40237v3 onion services require a "live" consensus to publish or fetch2022-07-07T00:48:32ZRoger Dingledinev3 onion services require a "live" consensus to publish or fetchIf the Tor v3 onion client, or Tor v3 onion service, do not have a "live" consensus (i.e. one where "valid-until" hasn't elapsed), then they will choose not to even attempt to fetch or publish v3 onion descriptors:
```
Jan 10 11:32:24.36...If the Tor v3 onion client, or Tor v3 onion service, do not have a "live" consensus (i.e. one where "valid-until" hasn't elapsed), then they will choose not to even attempt to fetch or publish v3 onion descriptors:
```
Jan 10 11:32:24.364 [warn] No live consensus so we can't get the responsible hidden service directories.
```
This bug got exposed today because the network went several rounds without a consensus due to the ongoing issues of #33018 and #33072, and thus Tor clients and Tor onion services ended up with a consensus that still worked (it was made within the past 24 hours), but was no longer considered "live".
So normal Tor circuits (using exit relays) still worked, and v2 onion services still worked, but v3 onion services stopped working for that time period -- services wouldn't publish descriptors, and clients wouldn't fetch them.
The fix imo is that we need to make v3 onion services work under the same time assumptions as the other parts of Tor -- if you have a usable consensus, then use it.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40236configure summary misleadingly indicates library support based on enable, not...2022-07-07T00:48:32ZAlex Xuconfigure summary misleadingly indicates library support based on enable, not havewhen --enable-zstd, --enable-lzma, etc are set to auto, they are listed in the configure summary as "no" regardless of whether they were detected and used.when --enable-zstd, --enable-lzma, etc are set to auto, they are listed in the configure summary as "no" regardless of whether they were detected and used.Tor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40234Non-fatal assertion !(smartlist_len(outdated_dirserver_list) > TOO_MANY_OUTDA...2022-07-07T00:48:32ZNick MathewsonNon-fatal assertion !(smartlist_len(outdated_dirserver_list) > TOO_MANY_OUTDATED_DIRSERVERS)A user sent me this email saying that they'd gotten this bug on their relay.
```
tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:133:
microdesc_note_outdated_dirserver: Non-fatal assertion
!(smartlist_len(outdated_dirserv...A user sent me this email saying that they'd gotten this bug on their relay.
```
tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:133:
microdesc_note_outdated_dirserver: Non-fatal assertion
!(smartlist_len(outdated_dirserver_list) > TOO_MANY_OUTDATED_DIRSERVERS)
failed. (on Tor 0.4.4.6 )
Bug: Tor 0.4.4.6: Non-fatal assertion
!(smartlist_len(outdated_dirserver_list) > TOO_MANY_OUTDATED_DIRSERVERS)
failed in microdesc_note_outdated_dirserver at
../src/feature/nodelist/microdesc.c:133. Stack trace: (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(log_backtrace_impl+0x56) [0x55bdb35379d6] (on Tor
0.4.4.6 )
Bug: /usr/bin/tor(tor_bug_occurred_+0x16c) [0x55bdb3532bdc] (on Tor
0.4.4.6 )
Bug: /usr/bin/tor(microdesc_note_outdated_dirserver+0x147)
[0x55bdb34563c7] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(+0x1085fb) [0x55bdb341d5fb] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(+0x10b588) [0x55bdb3420588] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(connection_dir_reached_eof+0x29) [0x55bdb3422e09]
(on Tor 0.4.4.6 )
Bug: /usr/bin/tor(connection_handle_read+0x8bc) [0x55bdb33862dc]
(on Tor 0.4.4.6 )
Bug: /usr/bin/tor(+0x76729) [0x55bdb338b729] (on Tor 0.4.4.6 )
Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba)
[0x7f0bd5d2e9ba] (on Tor 0.4.4.6 )
Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)
[0x7f0bd5d2f537] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(do_main_loop+0xff) [0x55bdb338c9af] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(tor_run_main+0x885) [0x55bdb33793a5] (on Tor
0.4.4.6 )
Bug: /usr/bin/tor(tor_main+0x3a) [0x55bdb33772ca] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(main+0x19) [0x55bdb3376e89] (on Tor 0.4.4.6 )
Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)
[0x7f0bd561009b] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(_start+0x2a) [0x55bdb3376eda] (on Tor 0.4.4.6 )
```Tor: 0.4.5.x-stableNick MathewsonNick Mathewson