Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-07-07T00:48:31Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40190Delaying hostname send in SOCKS5 `CONNECT` command causes failure in hostname...2022-07-07T00:48:31ZZmnSCPxjDelaying hostname send in SOCKS5 `CONNECT` command causes failure in hostname resolutionTested on systems
-----------------
* Linux 5.8.0-7625-generic amd64, Tor 0.4.2.7
* FreeBSD 11.2-RELEASE-p15 amd64, Tor 0.4.4.5
Replication
-----------
SOCKS5 has the below specification for the request (RFC1928)
```
The SOCKS req...Tested on systems
-----------------
* Linux 5.8.0-7625-generic amd64, Tor 0.4.2.7
* FreeBSD 11.2-RELEASE-p15 amd64, Tor 0.4.4.5
Replication
-----------
SOCKS5 has the below specification for the request (RFC1928)
```
The SOCKS request is formed as follows:
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Where:
o VER protocol version: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet
order
```
To replicate:
* Send the `VER`, `CMD`, `RSV`, and `ATYP` bytes (4 bytes) in a single `write`.
* Wait a short while.
* Send the rest of the request (`DST.ADDR`, `DST.PORT`) in another `write`.
This consistently leads to hostname resolution failure as logged in the Tor logs.
Test Code
---------
```c
#include<netinet/in.h>
#include<netinet/ip.h>
#include<stdint.h>
#include<stdio.h>
#include<string.h>
#include<sys/socket.h>
#include<sys/types.h>
#include<unistd.h>
static
const short proxy_port = 9050;
#define PROXY_HOST htonl(INADDR_LOOPBACK)
static
const char* hostname = "www.google.com";
static
const short port = 443;
int main() {
uint8_t buffer[1024];
int fd;
struct sockaddr_in si;
short n_port;
int success = 0;
fd = socket(AF_INET, SOCK_STREAM, 0);
si.sin_family = AF_INET;
si.sin_port = htons(proxy_port);
si.sin_addr.s_addr = PROXY_HOST;
connect(fd, (const struct sockaddr*) &si, sizeof(si));
buffer[0] = 0x05; /* SOCKS5 */
buffer[1] = 0x01; /* Number of authentication methods*/
buffer[2] = 0x00; /* No authentication. */
write(fd, buffer, 3);
buffer[0] = ~0x05;
buffer[1] = ~0x00;
read(fd, buffer, 2);
if (buffer[0] != 0x05)
fprintf(stderr, "Unexpected response from proxy, expecting SOCKS5\n");
if (buffer[1] != 0x00)
fprintf(stderr, "Unexpected response from proxy, expecting unauthenticated\n");
buffer[0] = 0x05; /* SOCKS5 */
buffer[1] = 0x01; /* CMD CONNECT */
buffer[2] = 0x00; /* RSV */
buffer[3] = 0x03; /* ATYP DOMAINNAME */
write(fd, buffer, 4);
/* This delay, should not affect the behavior of a proxy! */
usleep(1000); /* 1ms */
/* If the above delay is commented out, *sometimes* on my
* system this program succeeds and prints "connected",
* *sometimes* it fails and prints "not connected".
* With the above 1-millisecond delay, it always prints
* "not connected".
* Without the above delay, if I run in any kind of test
* harness (`strace`, `valgrind`) it always says "not
* connected", suggesting that any minor delay after
* `ATYP` can trigger this.
*/
buffer[0] = (uint8_t)strlen(hostname);
memcpy(&buffer[1], hostname, (size_t) buffer[0]);
write(fd, buffer, 1 + ((size_t) buffer[0]));
n_port = htons(port);
memcpy(&buffer[0], &n_port, 2);
write(fd, buffer, 2);
buffer[0] = ~0x05;
buffer[1] = ~0x00;
read(fd, buffer, 2);
if (buffer[0] != 0x05)
fprintf(stderr, "Unexpected response from proxy, expecting SOCKS5\n");
success = (buffer[1] == 0x00);
close(fd);
if (success)
fprintf(stdout, "Connected.\n");
else
fprintf(stdout, "Not connected.\n");
return 0;
}
```
Notes
-----
In principle, it should not matter if I send all of the data in a single `write`, or if I want to send each individual byte into its own `write` with a 100-millisecond delay each. This is supposedly a TCP stream socket, after all; such timing delays may matter on datagram-based sockets, but in principle not to stream sockets (where all that *should* matter is ordering of bytes).
`curl --socks5-hostname` and `torify wget` do not tickle this bug since they consistently send the entire request in a single `write`/`sendto`.
This suggests to me that some layer inside Tor is triggering the hostname lookup as soon as it receives `ATYP` and simply assumes that the entire hostname has been received, without actually verifying that the `DST.ADDRESS` after `ATYP` was ***actually*** received. The problem is that this layer inside Tor may be reading an uninitialized buffer with all the security problems that implies, **and** sending it out to a remote resolver. This was not easy to spot as well, since Tor logs will show hostnames it failed to look up as `[Scrubbed]`, and I spent a lot of time looking for other bugs in my code before I thought to look into the behavior of Tor.
This might not be a high priority issue, since it seems most commodity libraries and tools send the entire request as a single `write`, it was only my own internal library that, for code simplicicty, wrote the hostname (stored in a different buffer) separately from the `VER` `CMD` `RSV` `ATYP` sequence. However, others reimplementing a simple SOCKS5 client might stumble into this as well, since typically in TCP it does not matter how many `write`s you use to send the data, as long as the order of bytes is correct.
Marked as confidential as I suspect Tor may be triggered into reading uninitialized buffers and possibly sending the contents of that buffer to a remote node.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40128Libressl 3.2.1 with compatibility issues to Tor relays2022-07-07T00:48:31ZFelixLibressl 3.2.1 with compatibility issues to Tor relaysHi all
After upgrade of Ichotolot60 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E from 4.2.7 to 4.4.5 it dropped off consensus.
Apr 02 21:51:31.872 [notice] Tor 0.4.2.7 running on FreeBSD with Libevent 2.1.11-stable, OpenSSL LibreSSL 3.0.2...Hi all
After upgrade of Ichotolot60 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E from 4.2.7 to 4.4.5 it dropped off consensus.
Apr 02 21:51:31.872 [notice] Tor 0.4.2.7 running on FreeBSD with Libevent 2.1.11-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4.
The consensus-health on April/9 shows all auths see it running.
Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5.
The consensus-health after one day shows:
```
moria1 Fast Run Stab V2Dir Valid bw=566
tor26 Fast Guard Stab V2Dir Valid
dizum Fast Guard Stab V2Dir Valid
gabel. Fast Stab V2Dir Valid bw=1130
danne. Fast Guard Run Stab V2Dir Valid
maatu. Fast Stab V2Dir Valid bw=1200
farav. Fast Guard Run Stab V2Dir Valid bw=2970
longc. Fast Stab V2Dir Valid bw=490
bastet Fast Guard Run Stab V2Dir Valid bw=3520
bwauth=n/a
```
Sep 20 10:30:45.633 [notice] Tor 0.4.4.5 running on FreeBSD with
Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.0, Zlib 1.2.11, Liblzma
5.2.4, and Libzstd 1.4.5.
The consensus-health shows 2 hours after Libressl 321 -> 320
```
moria1 Fast Run Stab V2Dir Valid bw=566
tor26 Fast Run Stab V2Dir Valid
dizum Fast Run Stab V2Dir Valid
gabel. Fast Run Stab V2Dir Valid bw=1130
danne. Fast -Guard Run Stab V2Dir Valid
maatu. Fast Run Stab V2Dir Valid bw=1200
farav. Fast -Guard Run Stab V2Dir Valid bw=2970
longc. !Fast Run Stab V2Dir Valid bw=70
bastet Fast -Guard Run Stab V2Dir Valid bw=3520
bwauth=gabelmoo
```
**Libressl 321 is not compatible to the authorities tor26, dizum, gabel., maatu. and longc. to grant a "Running.** What can that be?
:: Legacy ::
We had the same trouble with Libressl 292 when 28x worked well and
30x too.
With Libressl292 the consensus-health showed Sep/7 _2019_
ACBBB426CE1D0641A590BF1FC1CF05416FC0FF6F Planetclaire62
```
Fast !Running Stable V2Dir Valid bw=8200
Fast !Running Stable V2Dir Valid
!Fast Running Stable V2Dir Valid
Fast !Running Stable V2Dir Valid
!Fast Running Stable V2Dir Valid
Fast !Running Stable V2Dir Valid
Fast Running Stable V2Dir Valid bw=747
Fast Guard HSDir Running Stable V2Dir Valid
Fast Guard HSDir Running Stable V2Dir Valid bw=8180
Fast Running Stable V2Dir Valid bw=8180
bwauth=faravahar
```Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://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/40099rend_cache/clean_v2_descs_as_dir fails when run on its own2022-07-07T00:48:31ZNick Mathewsonrend_cache/clean_v2_descs_as_dir fails when run on its ownTry to run the rend_cache/clean_v2_descs_as_dir test on its own, and it reports:
```
$ ./src/test/test rend_cache/clean_v2_descs_as_dir
rend_cache/clean_v2_descs_as_dir: Aug 12 14:16:28.470 [warn] rend_cache_decrement_allocation(): Bug: ...Try to run the rend_cache/clean_v2_descs_as_dir test on its own, and it reports:
```
$ ./src/test/test rend_cache/clean_v2_descs_as_dir
rend_cache/clean_v2_descs_as_dir: Aug 12 14:16:28.470 [warn] rend_cache_decrement_allocation(): Bug: Underflow in rend_cache_decrement_allocation (on Tor 0.3.5.11-dev 70aaf3bdd8e4527a)
[clean_v2_descs_as_dir FAILED]
1/1 TESTS FAILED. (0 skipped)
```Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40097tor stops boostrapping on Android2022-07-07T00:48:31ZNathan Freitastor stops boostrapping on AndroidWe've been seeing an issue intermittently on Orbot / Android for awhile now, on tor 0.4.2.x and 0.4.3.x as well. After running just fine for weeks and months even, tor will just stop bootstrapping. The process starts successfully, the co...We've been seeing an issue intermittently on Orbot / Android for awhile now, on tor 0.4.2.x and 0.4.3.x as well. After running just fine for weeks and months even, tor will just stop bootstrapping. The process starts successfully, the control port is available, but nothing happens after that.
We have narrowed it down to some kind of corruption in the DataDirectory. If you change the path of that, it bootstraps fine. If you set it back to the original path, it is stuck again.
You can see more data and details on the DataDirectory state and control port events here:
https://github.com/guardianproject/orbot/issues/285
I am trying to get an export of the non-bootstrapping DataDirectory so we can look at the contents of each file.
Otherwise, is there a known issue with this type of corruption / non-bootstrapping state?Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40072sandbox is broken in 0.4.4.3-alpha2022-07-07T00:48:30Ztoralfsandbox is broken in 0.4.4.3-alphacommit d28bfb2cd566 of issue #40020 doesn't work here at a hardened stable Gentoo Linux - the error is
```
Jul 27 15:28:29.000 [warn] Directory /var/lib/tor/data cannot be read: Operation not permitted
Jul 27 15:28:29.000 [err] Can't cre...commit d28bfb2cd566 of issue #40020 doesn't work here at a hardened stable Gentoo Linux - the error is
```
Jul 27 15:28:29.000 [warn] Directory /var/lib/tor/data cannot be read: Operation not permitted
Jul 27 15:28:29.000 [err] Can't create/check datadirectory /var/lib/tor/data
Jul 27 15:28:29.000 [err] Error initializing keys; exiting
```
reverting it circumvents the issue here.
```
# emerge -qpvO glibc
[ebuild R ] sys-libs/glibc-2.30-r8 USE="(crypt) multiarch (ssp) (static-libs) -audit -caps (-cet) -compile-locales -custom-cflags -doc -gd -headers-only (-multilib) -nscd -profile (-selinux) -suid -systemtap -test (-vanilla)"
# uname -a
Linux mr-fox 5.7.10 #13 SMP Wed Jul 22 16:36:05 CEST 2020 x86_64 Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux
```Tor: 0.4.4.x-finalJigsaw52Jigsaw52https://gitlab.torproject.org/tpo/core/tor/-/issues/40035NSS needs to be told that its sockets are nonblocking2022-07-07T00:48:30ZNick MathewsonNSS needs to be told that its sockets are nonblockingApparently NSS does not automatically realize that its SSL sockets are nonblocking when you construct them around a nonblocking TCP socket. You have to make them nonblocking yourself.
Found while investigating #40018. Root cause of #40...Apparently NSS does not automatically realize that its SSL sockets are nonblocking when you construct them around a nonblocking TCP socket. You have to make them nonblocking yourself.
Found while investigating #40018. Root cause of #40018.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34382Don't require M_SYSCALL in sandbox.c2022-07-07T00:49:01ZNick MathewsonDon't require M_SYSCALL in sandbox.cIn sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we ...In sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we don't have it defined can still build with m_syscall.
See also legacy/trac#32904 and legacy/trac#30987Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34381Shellcheck warnings for no-longer-existent contrib scripts2022-07-07T00:49:01ZcShellcheck warnings for no-longer-existent contrib scripts```
% shellcheck --version
ShellCheck - shell script analysis tool
version: 0.7.1
```
Running `make check` results in a few warnings for both `contrib/dist/suse/tor.sh` and `contrib/dist/tor.sh`, namely SC2034 (unused variables) and SC2...```
% shellcheck --version
ShellCheck - shell script analysis tool
version: 0.7.1
```
Running `make check` results in a few warnings for both `contrib/dist/suse/tor.sh` and `contrib/dist/tor.sh`, namely SC2034 (unused variables) and SC2039 (POSIX incompatibilities). If shellcheck is right, then I can gladly go ahead and address these warnings in a PR.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34375Remove 0.4.1 from git-list-tor-branches.sh and add 0.4.42022-07-07T00:49:01ZNick MathewsonRemove 0.4.1 from git-list-tor-branches.sh and add 0.4.4Now that 0.4.1 is EOL, we can remove it from git-list-tor-branches.Now that 0.4.1 is EOL, we can remove it from git-list-tor-branches.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://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/34249Make sure the C and Rust protovers can't get out of sync2022-07-07T00:49:01ZteorMake sure the C and Rust protovers can't get out of syncThere is a recurring bug, where we modify the C protover, but forget the Rust protover. (See legacy/trac#34248, legacy/trac#33285, legacy/trac#29631 for similar issues.)
We could fix the underlying issue by fetching the string from a co...There is a recurring bug, where we modify the C protover, but forget the Rust protover. (See legacy/trac#34248, legacy/trac#33285, legacy/trac#29631 for similar issues.)
We could fix the underlying issue by fetching the string from a common location, using C's `#include` or Rust's `include_str!()`.
Then we could test that C and Rust are the same by putting a copy of the protover string in the unit tests, and making sure that it matches the currently supported protocol versions.
This fix and test will be important for proposal 318, because it will modify both protocol version implementations:
https://github.com/torproject/torspec/blob/master/proposals/318-limit-protovers.mdTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34245Declare variables in for loops in rend_service_dump_stats()2022-07-07T00:49:01ZNeel Chauhanneel@neelc.orgDeclare variables in for loops in rend_service_dump_stats()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34238Space out some function calls in parse_short_policy()2022-07-07T00:49:01ZNeel Chauhanneel@neelc.orgSpace out some function calls in parse_short_policy()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34237Fix spacing in if statement in tor_version_parse()2022-07-07T00:49:00ZNeel 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/tpo/core/tor/-/issues/34220Return to stem master once stem issue 63 is resolved.2022-07-07T00:49:00ZNick 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 legacy/trac#34204.When stem fixes https://github.com/torproject/stem/issues/63 , we should revert the travis.yml change of legacy/trac#34204.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34204Downgrade Travis stem version to a commit where tests pass.2022-07-07T00:49:00ZNick 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/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 Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/34084HSv3: Bug at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:7392021-06-23T17:22:42Zs7rHSv3: 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 legacy/trac#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 Kadianakis