Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-07-07T00:48:32Zhttps://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/40210Tor generates invalid address for hiddenservice when running on armv5tel arch...2021-07-09T17:22:00ZAlexander Færøyahf@torproject.orgTor generates invalid address for hiddenservice when running on armv5tel architectures (from Debian)@weasel posted the following ticket today on IRC from Debian issue tracker:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977
Maybe this is something we should look into? Looks like it's going back all the way to 0.3.5.@weasel posted the following ticket today on IRC from Debian issue tracker:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977
Maybe this is something we should look into? Looks like it's going back all the way to 0.3.5.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/40207Downgrade or fix what is triggering some rendezvous circuit related warning i...2021-06-23T17:22:08Zs7rDowngrade or fix what is triggering some rendezvous circuit related warning in client log filesWhen you create a large number of concurrent rendezvous circuits (as a client connecting to an .onion) you see often in the log file:
`[warn] Can't find any rendezvous circuit. Stopping`
and
`[warn] Unable to setup INTRODUCE1 data. Th...When you create a large number of concurrent rendezvous circuits (as a client connecting to an .onion) you see often in the log file:
`[warn] Can't find any rendezvous circuit. Stopping`
and
`[warn] Unable to setup INTRODUCE1 data. The chosen rendezvous point is unusable. Closing circuit.`
Since I can see no other bug related info surrounding these except #34083 (I've also run in debug mode) it seams like there's nothing the user can do about them, and it requires no action from user side and the user basically learns nothing from them. So, if they cannot be triggered by an actual bug or help us learn anything or discover a bug, maybe we should make them less alarming and downgrade the severity. If they are helpful for discovering other potential bugs, we should allow them. It's only occurring on heavily used clients.Tor: 0.4.5.x-stableNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40169Circuit Build Timeout code needs cleanup2023-06-08T17:51:54ZMike PerryCircuit Build Timeout code needs cleanupThere's two places where we time out circuits: `circuit_expire_building` and `circuit_build_times_handle_completed_hop()`. `circuit_expire_building` is filled with 19 years of cruft and complexity, and only operates on the *second* resol...There's two places where we time out circuits: `circuit_expire_building` and `circuit_build_times_handle_completed_hop()`. `circuit_expire_building` is filled with 19 years of cruft and complexity, and only operates on the *second* resolution, instead of milliseconds.
These probably only affect timeout in rare cases -- https://gitlab.torproject.org/tpo/core/tor/-/issues/40157 seems to show that with fixes from https://gitlab.torproject.org/tpo/core/tor/-/issues/40168, then we get very close to the target 20% timeout. But there's so much old cruft here that we should clean it up anyway. It might affect UX very poorly in some edge cases.
This is especially true for onion services, which rely primarily on `circuit_expire_building()`. There's likely many bad performance consequences of this, for them.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40125hs-v2: The rend_cache/entry_free test underflows rend_cache_decrement_allocat...2021-06-23T17:22:08ZDavid Gouletdgoulet@torproject.orghs-v2: The rend_cache/entry_free test underflows rend_cache_decrement_allocation()For some reasons, the test `rend_cache/entry_free` recently started to fail with:
> rend_cache/entry_free: Sep 17 08:40:13.845 [warn] rend_cache_decrement_allocation(): Bug: Underflow in rend_cache_decrement_allocation (on Tor 0.4.5.0-a...For some reasons, the test `rend_cache/entry_free` recently started to fail with:
> rend_cache/entry_free: Sep 17 08:40:13.845 [warn] rend_cache_decrement_allocation(): Bug: Underflow in rend_cache_decrement_allocation (on Tor 0.4.5.0-alpha-dev 7eef9ced61e72b1d)
And this is actually quite obvious by looking at the test that it would underflow all the time since the total cache size is never incremented but we decrement it when freeing.
This requires backport for the CI to pass on all our versions.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40117Onion service rendezvous cell statistics don't count client->service traffic.2022-07-07T00:48:31ZGeorge KadianakisOnion service rendezvous cell statistics don't count client->service traffic.While working on #23126 we found that v2 rendezvous cell stats don't count client->service traffic.
The patch is pretty simple, but will probably influence the shape of the graphs at https://metrics.torproject.org/hidserv-rend-relayed-c...While working on #23126 we found that v2 rendezvous cell stats don't count client->service traffic.
The patch is pretty simple, but will probably influence the shape of the graphs at https://metrics.torproject.org/hidserv-rend-relayed-cells.html .Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/40109Does every new consensus disable IntroDosDefense?2022-10-11T23:39:35ZRoger DingledineDoes every new consensus disable IntroDosDefense?In handle_establish_intro_cell_dos_extension(), when the intro point receives an extension asking it to enable the rate limiting feature, it does:
```
/* We passed validation, enable defenses and apply rate/burst. */
circ->introduce2...In handle_establish_intro_cell_dos_extension(), when the intro point receives an extension asking it to enable the rate limiting feature, it does:
```
/* We passed validation, enable defenses and apply rate/burst. */
circ->introduce2_dos_defense_enabled = 1;
/* Initialize the INTRODUCE2 token bucket for the rate limiting. */
token_bucket_ctr_init(&circ->introduce2_bucket,
(uint32_t) intro2_rate_per_sec,
(uint32_t) intro2_burst_per_sec,
(uint32_t) approx_time());
```
But then later, in hs_dos_consensus_has_changed() we call set_consensus_parameters(ns) which resets some global variables about what we think the consensus says (so far so good), and then it calls update_intro_circuits() which goes through the list of established intro points and
```
SMARTLIST_FOREACH_BEGIN(intro_circs, circuit_t *, circ) {
/* Defenses might have been enabled or disabled. */
TO_OR_CIRCUIT(circ)->introduce2_dos_defense_enabled =
consensus_param_introduce_defense_enabled;
/* Adjust the rate/burst value that might have changed. */
token_bucket_ctr_adjust(&TO_OR_CIRCUIT(circ)->introduce2_bucket,
consensus_param_introduce_rate_per_sec,
consensus_param_introduce_burst_per_sec);
} SMARTLIST_FOREACH_END(circ);
```
It sure looks to me like this is *overwriting* the values requested in the intro cell DoS extension.
And since the consensus right now doesn't have these consensus params set, then they will be reset to their defaults ("disabled", "25", "200") for every intro point every time a new consensus is processed by the intro point.
If this is so, then it sure seems like we want to set some flag on the intro point, called "I am using explicit values rather than the default", and if that flag is set then we don't mess with it when processing a new consensus.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40108ADD_ONION command returns "Missing 'Port' argument" when null terminator is p...2022-09-01T21:42:49ZrichardADD_ONION command returns "Missing 'Port' argument" when null terminator is present at endSo I naively sent:
"ADD_ONION ED25519-V3:$(base64PrivateKey)\0"
over the control port including the NULL terminator from my C string. Rather than yelling at me for sending non-printable characters (or something similar), the command...So I naively sent:
"ADD_ONION ED25519-V3:$(base64PrivateKey)\0"
over the control port including the NULL terminator from my C string. Rather than yelling at me for sending non-printable characters (or something similar), the command returned "Missing 'Port' argument"
Seems weird.
EDIT:
tor --version -> "Tor version 0.4.3.6"https://gitlab.torproject.org/tpo/core/tor/-/issues/40100Mixing long lived streams with shorter connections causes hidden tor service ...2021-07-09T17:30:28Ztubby-torMixing long lived streams with shorter connections causes hidden tor service name (.onion) resolution/routing failuresFrom one single tor instance with default settings and a single client address, long-lived streams to some .onion addresses seems to eventually break name resolution/routing to other .onion addresses that are short-lived connections.
Fo...From one single tor instance with default settings and a single client address, long-lived streams to some .onion addresses seems to eventually break name resolution/routing to other .onion addresses that are short-lived connections.
For example:
- Copy a large file over ssh from Client to server a.onion, b.onion, c.onion. (simultaneously for several hours)
- Connect to server d.onion, e.onion, f.onion for a few commands, then disconnect several times during the long running streams.
Eventually and intermittently, connections to d.onion, e.onion, f.onion fail on the client-side only.
Tests to isolate the problem:
- Testing the connections from another clients works, confirming that the servers d.onion, e.onion, f.onion are still up and it is a problem with the client-side tor
- Forcing a `SIGNAL NEWNYM` on the client corrects the problem and the client can subsequently connect to d.onion, e.onion, f.onion. The bad side-effect is that all the long-running streams are disconnected (of course).
- Forcing very aggressive circuit rebuilding on the client-side tor mostly solves the problem but also causes more disconnection of streams. I haven't been able to isolate further which one of these options is actually fixing the problem, but providing these are further information for others.
```
KeepalivePeriod 1
LongLivedPorts
MaxCircuitDirtiness 30
NewCircuitPeriod 30
```
- Stream Isolation `SocksPort ... IsolateDestAddr` did NOT seem to help.
I suspect that stale circuits are remaining opened for the long-running streams and that even though they keep streaming, they can no longer resolve/route new .onion requests and thus fail.
I think that tor with default configuration should be robust in these situations and there should not be an obscure .onion name resolution/routing failre to connect to hosts. Most users will not be able to diagnose such a situation and will also have trouble resolving it, ultimately giving the impression that .onion services are unreliable, regardless of whether it is .onion server side failure or client side .onion name resolution or routing failure.
I am not specifically looking for a solution, since I have many workarounds, simply trying to report the issue in a way that may help the tor project.
I have NOT tested the same problem using clearnet IP or domain name based servers, so I cannot report if it is specific to .onion or more general to all client-side tor circuits.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40090ONION_CLIENT_AUTH_ADD persistence error unhelpfully vague2022-02-28T19:41:25ZDamian JohnsonONION_CLIENT_AUTH_ADD persistence error unhelpfully vagueI tried to add an integ test for persisting hidden service credentials to disk (calling ONION_CLIENT_AUTH_ADD with a "Permanent" flag) but the error response I received from tor is unhelpfully vague...
> Unable to store creds for "yvhz3...I tried to add an integ test for persisting hidden service credentials to disk (calling ONION_CLIENT_AUTH_ADD with a "Permanent" flag) but the error response I received from tor is unhelpfully vague...
> Unable to store creds for "yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid"
It's possible that there's an issue on my end, or also possible that the feature doesn't work. Unfortunately this response is too nebulous for me to troubleshoot.https://gitlab.torproject.org/tpo/core/tor/-/issues/40089ONION_CLIENT_AUTH_ADD client names aren't persisted2021-06-23T17:22:08ZDamian JohnsonONION_CLIENT_AUTH_ADD client names aren't persistedONION_CLIENT_AUTH_ADD is documented as accepting a ClientName, but ONION_CLIENT_AUTH_VIEW is failing to echo these names back as proscribed by the spec...
```
Sent to tor: ONION_CLIENT_AUTH_ADD yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7...ONION_CLIENT_AUTH_ADD is documented as accepting a ClientName, but ONION_CLIENT_AUTH_VIEW is failing to echo these names back as proscribed by the spec...
```
Sent to tor: ONION_CLIENT_AUTH_ADD yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid x25519:FCV0c0ELDKKDpSFgVIB8Yow8Evj5iD+GoiTtK878NkQ= ClientName=StemInteg
Received from tor: 250 OK
Sent to tor: ONION_CLIENT_AUTH_VIEW yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid
Received from tor:
250-ONION_CLIENT_AUTH_VIEW yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid
250-CLIENT yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid x25519:FCV0c0ELDKKDpSFgVIB8Yow8Evj5iD+GoiTtK878NkQ=
250 OK
```Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40084Controller support for creating authenticated onion services2021-06-23T17:22:08ZDamian JohnsonController support for creating authenticated onion services[As discussed on tor-dev@](https://lists.torproject.org/pipermail/tor-dev/2020-June/014377.html) the only way to create a v3 onion service with authentication is by writing files to disk within a 'authorized_clients' directory.
Our ADD_...[As discussed on tor-dev@](https://lists.torproject.org/pipermail/tor-dev/2020-June/014377.html) the only way to create a v3 onion service with authentication is by writing files to disk within a 'authorized_clients' directory.
Our ADD_ONION command can create authenticated v2 services via its 'BasicAuth' flag, and we can authenticate **to** a v3 service with ONION_CLIENT_AUTH_ADD. However, there isn't yet a controller mechanism to **create** a v3 service with authentication. This is intended to track that.Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40064hs: Implement self reachability test2021-09-27T16:40:27ZDavid Gouletdgoulet@torproject.orghs: Implement self reachability testI have not thought of the anonymity problem that could bring if any, just more of a pragmatic approach of how that could be useful.
Onion services sometimes can find themselves unable to publish a descriptor for many different reasons o...I have not thought of the anonymity problem that could bring if any, just more of a pragmatic approach of how that could be useful.
Onion services sometimes can find themselves unable to publish a descriptor for many different reasons or even bugs that we keep finding. Even under severe DDoS, they become unavailable but they don't know.
What if they would regularly do self reachability tests and in case of failure, they could do some "recovery actions" but also dumping their state so it is more easily debuggable.
But also, they could export that status onto something like tor#40063 which could inform very quickly the operator which in turn could correlate with the their stats if this is a tor problem or a DDoS or network issue or anything to that end.https://gitlab.torproject.org/tpo/core/tor/-/issues/40062Tor always overwrites onion service hostname file, but should leave it alone ...2021-06-23T17:22:07ZRoger DingledineTor always overwrites onion service hostname file, but should leave it alone if it shouldn't changeIf you start your Tor with an onion service, it will make the appropriate files in your onion service directory, e.g.
```
$ ls -la hidden_service
total 32
drwx------ 3 arma arma 4096 Jul 24 05:14 .
drwxrwxrwt 21 root root 12288 Jul 24 ...If you start your Tor with an onion service, it will make the appropriate files in your onion service directory, e.g.
```
$ ls -la hidden_service
total 32
drwx------ 3 arma arma 4096 Jul 24 05:14 .
drwxrwxrwt 21 root root 12288 Jul 24 05:11 ..
drwx------ 2 arma arma 4096 Jul 24 05:11 authorized_clients
-rw------- 1 arma arma 63 Jul 24 05:14 hostname
-rw------- 1 arma arma 64 Jul 16 00:11 hs_ed25519_public_key
-rw------- 1 arma arma 96 Jul 16 00:11 hs_ed25519_secret_key
```
but if you then set the directory to read-only, Tor will fail to start, complaining
```
Jul 24 05:16:38.104 [warn] Couldn't open "/tmp/hidden_service//hostname.tmp" (/tmp/hidden_service//hostname) for writing: Permission denied
Jul 24 05:16:38.104 [warn] Could not write onion address to hostname file "/tmp/hidden_service//hostname"
Jul 24 05:16:38.104 [warn] Error loading rendezvous service keys
Jul 24 05:16:38.104 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.4.5.0-alpha-dev 5336ac26693cdba4)
```
Back in the day, I added some logic where it would first *read* the hostname file, and decide if it already has the correct content in it, and if it does, it would leave it alone (i.e. not try to write). It looks like either I misremembered doing that, or we lost that feature somewhere along the way.
If we resume doing that behavior, then people can set their onion service keys directory to be read-only, which will let them improve their opsec.
Bug reported by Jeff Moss on his Defcon onion.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40003hs-v2: Add a deprecation warning2021-06-23T17:22:07ZDavid Gouletdgoulet@torproject.orghs-v2: Add a deprecation warningWe've entered deprecation path for v2: https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.html
0.4.4.x series should be the first version to warn of deprecation.We've entered deprecation path for v2: https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.html
0.4.4.x series should be the first version to warn of deprecation.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34400control: HSFETCH command fails to validate v2 addresses2022-07-07T00:49:02ZDavid Gouletdgoulet@torproject.orgcontrol: HSFETCH command fails to validate v2 addressesIn `handle_control_hsfetch()`:
```
} else if (strcmpstart(arg1, v2_str) == 0 &&
rend_valid_descriptor_id(arg1 + v2_str_len) &&
base32_decode(digest, sizeof(digest), arg1 + v2_str_len,
...In `handle_control_hsfetch()`:
```
} else if (strcmpstart(arg1, v2_str) == 0 &&
rend_valid_descriptor_id(arg1 + v2_str_len) &&
base32_decode(digest, sizeof(digest), arg1 + v2_str_len,
REND_DESC_ID_V2_LEN_BASE32) ==
REND_DESC_ID_V2_LEN_BASE32) {
```
The above snippet is how we validate the v2 address for the `HSFETCH` command. The `base32_decode()` function returns the number of bytes _decoded_ and thus it should returns on success `sizeof(digest)`, not the total length of the base32 address (20 vs 32).
Issue was introduced in commit `a517daa56f5848d25ba79617a1a7b82ed2b0a7c0` meaning since 0.4.1.1-alpha (ticket legacy/trac#28913).
I noticed this because I recently updated the bad HSDirscanner Tor to use our latest and it broke the scanner.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34299man page has wrong default for MinUptimeHidServDirectoryV22022-07-07T00:49:01ZRoger Dingledineman page has wrong default for MinUptimeHidServDirectoryV2In legacy/trac#14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the ...In legacy/trac#14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the man page.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34254Jenkins fails with hs_service.c:3118:3: error: comparison of unsigned express...2022-07-07T00:49:01ZGeorge KadianakisJenkins fails with hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenk...```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenkins.torproject.org/job/tor-ci-windows-master/659/consoleFull
Seems to be a by-product of legacy/trac#33400.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/34087HSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circ2021-06-23T17:22:07Zs7rHSv3: 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/tpo/core/tor/-/issues/34086HSv3: Bug Non-fatal assertion in hs_client.c:776: client_rendezvous_circ_has_...2021-06-23T17:22:07Zs7rHSv3: 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-finalGeorge KadianakisGeorge Kadianakis