Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:36Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34237Fix spacing in if statement in tor_version_parse()2020-06-13T15:53:36ZNeel Chauhanneel@neelc.orgFix spacing in if statement in tor_version_parse()This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34236Fix spacing in if statement in port_parse_config()2020-06-13T15:53:35ZNeel Chauhanneel@neelc.orgFix spacing in if statement in port_parse_config()This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34233Fix use of == in configure.ac2020-06-13T15:53:35ZNick MathewsonFix use of == in configure.acA user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our #34078 fix.A user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our #34078 fix.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34232Make summarize_protover_flags() handle NULL and empty string the same2020-06-13T15:53:34ZteorMake summarize_protover_flags() handle NULL and empty string the samesummarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline t...summarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline that functions should treat NULL and "" in similar ways. (Or the difference should be clearly documented.)
So we should ignore "" protovers, the same way we ignore NULL protovers. (Relays with empty protovers won't end up in the consensus, and clients can't use them for anything. So this change should have no real impact.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34220Return to stem master once stem issue 63 is resolved.2020-06-13T15:53:34ZNick MathewsonReturn to stem master once stem issue 63 is resolved.When stem fixes https://github.com/torproject/stem/issues/63 , we should revert the travis.yml change of #34204.When stem fixes https://github.com/torproject/stem/issues/63 , we should revert the travis.yml change of #34204.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34211Add support for control signals (ex. Ctrl+C) in Windows2020-06-13T15:53:33ZTracAdd support for control signals (ex. Ctrl+C) in WindowsHi everyone!
I am working on a [cross-platform Tor controller/wrapper](https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen), and I encountered a minor inconvenience while writing code for stopping Tor in Windows.
Currently the on...Hi everyone!
I am working on a [cross-platform Tor controller/wrapper](https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen), and I encountered a minor inconvenience while writing code for stopping Tor in Windows.
Currently the only way to gracefully terminate Tor in Windows is to use the control port to issue the `SIGINT` signal, it would be beneficial for 3rd party programs which work with Tor to be able to invoke this procedure by using the native "control signals" provided to console programs in Windows.
I have made a patch which implements this functionality, I will post it soon, I am creating this ticket so that I can create a corresponding file in the `changes` directory :)
Thanks to nickm for some pointers about using the libevent `event_active` function to trigger the event, I decided to use the `activate_signal` function as it internally calls the suggested function and simplifies the code.
**Trac**:
**Username**: TheDcoderTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34204Downgrade Travis stem version to a commit where tests pass.2020-06-13T15:53:32ZNick MathewsonDowngrade Travis stem version to a commit where tests pass.Due to https://github.com/torproject/stem/issues/63 our CI is failing. Let's downgrade to a working version of Stem unless it gets fixed right away.
I have a test PR at https://github.com/torproject/tor/pull/1889 ; if CI passes, I'll m...Due to https://github.com/torproject/stem/issues/63 our CI is failing. Let's downgrade to a working version of Stem unless it gets fixed right away.
I have a test PR at https://github.com/torproject/tor/pull/1889 ; if CI passes, I'll make PRs for the other branches and put this in needs_review.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34200Refactor tor's circuit path node selection checks2020-06-13T15:53:32ZteorRefactor tor's circuit path node selection checksIn #33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.In #33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.Tor: 0.4.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/34167PublishServerDescriptor via IPv62020-06-13T15:53:30ZTracPublishServerDescriptor via IPv6let my relay node configurable by what protocol the upload to authorities is done. similiar to
```
PublishServerDescriptor
```
option.
perhaps add option like
```
PublishServerDescriptorProtocol auto|4|6|or
# This option specifi...let my relay node configurable by what protocol the upload to authorities is done. similiar to
```
PublishServerDescriptor
```
option.
perhaps add option like
```
PublishServerDescriptorProtocol auto|4|6|or
# This option specifies how descriptors Tor will publish when acting as
# a relay. You can
# choose multiple arguments, separated by commas.
#
# If this option is set to 4, Tor will publish its
# descriptors to any directories over IPv4. (This is useful if you're not IPv6 connectable
# out your server, or if you're using a IPv6 Translation Tunnel)
# Otherwise, Tor will publish its
# descriptors via IPv6. The default is "auto", which
# means "if running as a relay or bridge, publish descriptors to the
# appropriate authorities over what's reachable". Other possibilities are "or", meaning
# "publish as if you're a OnionService", "publish over onion circuit".
```
_may Sponsor55 or prop311-prop313 already covered if i missed or could be relevant for_
**Trac**:
**Username**: ϲypherpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34139Build Tor without warnings or test failures with OpenSSL 3.0.02020-06-13T15:53:30ZNick MathewsonBuild Tor without warnings or test failures with OpenSSL 3.0.0According to the OpenSSL release strategy [release-strat] they're planning to release openssl 3.0.0 in early Q4 of this year.
Currently, many of the APIs that Tor uses are deprecated in OpenSSL 3.0.0-alpha [openssl-3]. It's still poss...According to the OpenSSL release strategy [release-strat] they're planning to release openssl 3.0.0 in early Q4 of this year.
Currently, many of the APIs that Tor uses are deprecated in OpenSSL 3.0.0-alpha [openssl-3]. It's still possible to build Tor with it, but you get a lot of deprecated-item warnings. We should fix those warnings before OpenSSL 3 is released.
Further, if we build without fatal warnings, there are some test failures. We should see if they are tor bugs or new openssl bugs, and fix them in the first case or report them in the second.
I don't think we necessarily need to backport this: OpenSSL 1.1 will be supported until 2023-09-11 [release-strat], whereas support for 0.3.5 is scheduled to end on 2020-02-02.
[release-strat] https://www.openssl.org/policies/releasestrat.html
[openssl-3] https://www.openssl.org/blog/blog/2020/04/23/OpenSSL3.0Alpha1/Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34137Make sure inform_testing_reachability() reports the correct ports2020-06-13T15:53:29ZteorMake sure inform_testing_reachability() reports the correct portsIn #33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that ...In #33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that it logs the actual reachability tests that are being run. (Rather than re-checking the relay's own routerinfo, which may have changed since the most recent reachability checks were launched.)
But inform_testing_reachability() is called when:
* the first circuit finishes building, or
* tor is reconfigured, and some circuits have already finished building.
So we need to do a bit of a refactor.
The refactor should preserve this behaviour:
* don't log until after the first circuit has finished building (rather than logging as soon as we start building reachability circuits)
And introduce this new behaviour:
* log the ports that were tested recently, rather than the ports that are currently available.
As an alternative, we could move some of the logging into the functions that actually launch the checks. And elevate some of those logs to notice level. (Note that these checks can be launched from at least 4 different locations in tor's code.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34133Tor documentation missing sandbox and %include limitations2020-06-13T15:53:28ZJigsaw52Tor documentation missing sandbox and %include limitationsThe tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.The tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34131Fix logic error in parse_extended_hostname2020-06-13T15:53:27ZNick MathewsonFix logic error in parse_extended_hostnameFound with a new clang warning:
```
log_warn(LD_APP, "Invalid %shostname %s; rejecting",
(*type_out == (ONION_V2_HOSTNAME || ONION_V3_HOSTNAME) ? "onion " : ""),
safe_str_client(address));
```Found with a new clang warning:
```
log_warn(LD_APP, "Invalid %shostname %s; rejecting",
(*type_out == (ONION_V2_HOSTNAME || ONION_V3_HOSTNAME) ? "onion " : ""),
safe_str_client(address));
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34130Tor won't start with seccomp sandbox when compiled with --enable-nss2020-06-13T15:53:27ZJigsaw52Tor won't start with seccomp sandbox when compiled with --enable-nssAfter compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-st...After compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-stable, NSS 3.35, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3.
May 06 21:47:46.198 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 06 21:47:46.198 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 06 21:47:46.198 [notice] Read configuration file "/home/daniel/Desktop/torrc_sandbox".
May 06 21:47:46.200 [notice] Opening Socks listener on 127.0.0.1:9050
May 06 21:47:46.200 [notice] Opened Socks listener on 127.0.0.1:9050
May 06 21:47:46.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
May 06 21:47:46.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
May 06 21:47:46.000 [warn] TLS error PR_NO_ACCESS_RIGHTS_ERROR while constructing a client TLS context: Access Denied
May 06 21:47:46.000 [err] Error creating TLS context for Tor client.
May 06 21:47:46.000 [err] Error initializing keys; exiting
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34088circuit_build_times_update_alpha(): Bug: Could not determine largest build time2020-06-13T15:53:26Zs7rcircuit_build_times_update_alpha(): Bug: Could not determine largest build timeI don't think this is HSv3 ONLY related, but I can only make it happen while building large amounts of rendezvous circuits with reasonable concurrency (over 50). I am not assigning the tor-hs keyword for this reason, but sticking it to s...I don't think this is HSv3 ONLY related, but I can only make it happen while building large amounts of rendezvous circuits with reasonable concurrency (over 50). I am not assigning the tor-hs keyword for this reason, but sticking it to same master parent ticket.
All lines are the same. It is seen for like 130-160 times during the build of little over 100.000 rendezvous circuits.
```
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 136 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 137 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 138 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 139 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 140 circuits. (on Tor 0.4.4.0-alpha-dev )
```
EDIT: All lines are the same except it always abandons 0 out of N circuits and N is always different of course, increasing with +1 most of the times until the Bug warn disappears.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34087HSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circ2020-06-13T15:53:26Zs7rHSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circClient side HSv3 non fatal bug. It occurs like between ~20 - 30 times in a total of 100.000 built rendezvous circuits:
```
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_c...Client side HSv3 non fatal bug. It occurs like between ~20 - 30 times in a total of 100.000 built rendezvous circuits:
```
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(desc == NULL) failed in close_or_reextend_intro_circ at ../src/feature/hs/hs_client.c:981. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(hs_client_receive_introduce_ack+0x2f5) [0x55d8749cfe95] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(rend_process_relay_cell+0x226) [0x55d874a1e796] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xbe368) [0x55d874966368] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34086HSv3: Bug Non-fatal assertion in hs_client.c:776: client_rendezvous_circ_has_...2020-06-13T15:53:25Zs7rHSv3: Bug Non-fatal assertion in hs_client.c:776: client_rendezvous_circ_has_openedClient side HSv3 non fatal bug. It occurs like between ~50 - 70 times in a total of 100.000 built rendezvous circuits:
```
Apr 03 14:53:04.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:776: client_rendezvous_circ_ha...Client side HSv3 non fatal bug. It occurs like between ~50 - 70 times in a total of 100.000 built rendezvous circuits:
```
Apr 03 14:53:04.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:776: client_rendezvous_circ_has_opened: Non-fatal assertion !(!node_supports_v3_rendezvous_point(rp_node)) failed. (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(!node_supports_v3_rendezvous_point(rp_node)) failed in client_rendezvous_circ_has_opened at ../src/feature/hs/hs_client.c:776. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(circuit_has_opened+0x80) [0x55d874947810] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34084HSv3: Bug at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:7392020-06-13T15:53:24Zs7rHSv3: Bug at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:739Client side HSv3 non fatal bug. It occurs like between ~80-120 times in a total of 100.000 built rendezvous circuits.
Seems like Tor is unable to find the right pubkey to assign to the introduction circuit and this causes a wave of asse...Client side HSv3 non fatal bug. It occurs like between ~80-120 times in a total of 100.000 built rendezvous circuits.
Seems like Tor is unable to find the right pubkey to assign to the introduction circuit and this causes a wave of asserts (also see dup #34085).
```
Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:739: setup_intro_circ_auth_key: This line should not have been reached. (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Line unexpectedly reached at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:739. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(hs_client_circuit_has_opened+0x342) [0x55d8749ceb22] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
```
This gets shortly followed by:
```
Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:518: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at ../src/feature/hs/hs_client.c:518. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(hs_client_send_introduce1+0x271) [0x55d8749ce5e1] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_ap_handshake_attach_circuit+0x3bd) [0x55d874949d5d] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_ap_attach_pending+0x178) [0x55d87494e108] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
```Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/34083Client rendezvous circuit is no longer in circuit_wait but in pending_entry_c...2020-06-13T15:53:22Zs7rClient 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: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34082Master ticket for client side rendezvous circuit related bugs that cause reac...2020-06-13T15:53:22Zs7rMaster ticket for client side rendezvous circuit related bugs that cause reachability problems in HSv3 landThis is the master ticket for some reachability issues I discovered while stress testing my onionbalance v3 setup. They all occurred while handling HSv3 services.
At least two of them always occur together, but handling them as separate...This is the master ticket for some reachability issues I discovered while stress testing my onionbalance v3 setup. They all occurred while handling HSv3 services.
At least two of them always occur together, but handling them as separate tickets for now and keeping this master ticket to glue them together, since they all mention different stack traces.Tor: unspecified