Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-02-05T21:03:36Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40204Travis chutney tests are borked by two bad commits2021-02-05T21:03:36ZGeorge KadianakisTravis chutney tests are borked by two bad commitsSeems like Travis chutney tests have been broken for the past 7 days. I did some investigation today using git-bisect and found out that there are two offending commits that both need to be reverted for the tests to pass.
These two comm...Seems like Travis chutney tests have been broken for the past 7 days. I did some investigation today using git-bisect and found out that there are two offending commits that both need to be reverted for the tests to pass.
These two commits are 1588767e655f87f49cf0f71d6e604117be52a135 and 4382e977f74e41f65170b4d9292678859c9e521f. Reverting just one of them won't do it and both of them need to be reverted for the tests to pass.
We should fix this so that we start getting a proper CI again.Tor: 0.4.6.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40200Tor is slow to reconnect after network connectivity change2022-06-17T16:13:16ZlhiTor is slow to reconnect after network connectivity changeTBB takes several minutes to become usable again in the following situation:
I'm on a laptop and use hibernate. Network interface is shut down before hibernating, after resuming I randomize the MAC and thus get a new IP.
Tor browser st...TBB takes several minutes to become usable again in the following situation:
I'm on a laptop and use hibernate. Network interface is shut down before hibernating, after resuming I randomize the MAC and thus get a new IP.
Tor browser stays open (I absolutely need persistent sessions to work efficiently).
After resume, it takes several minutes to recover during which all HTTP requests hang indefinitely.
* timeouts are set to values for often slow connections:
network.http.connection-retry-timeout 0
network.http.connection-timeout 120
network.http.keep-alive.timeout 180
network.http.response.timeout 300
network.http.network-changed.timeout 5
network.http.tls-handshake-timeout 60
* When I connect to the TBB's tor process, NEWNYM or new circuit works, but even after that, the browser remains stubbornly unresponsive.
* Last time I checked, kill -HUP (otherwise very useful in such situations) just kills the browser's tor process (?)
This behaviour is not new to me (at least 2-3 years), definitely impacts usability, but I can't find any existing bug report or discussion of it on the web.https://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/40189"tor-gencert --create-identity-key" fails with no clear error message if pass...2022-07-07T00:48:31ZRoger Dingledine"tor-gencert --create-identity-key" fails with no clear error message if passphrase is empty or shortRun tor-gencert to make a new key, but leave the PEM pass phrase empty (just hit enter):
```
$ ./tor-gencert --create-identity-key
Enter PEM pass phrase:
Nov 15 15:32:59.730 [err] Couldn't write identity key to ./authority_identity_key
N...Run tor-gencert to make a new key, but leave the PEM pass phrase empty (just hit enter):
```
$ ./tor-gencert --create-identity-key
Enter PEM pass phrase:
Nov 15 15:32:59.730 [err] Couldn't write identity key to ./authority_identity_key
Nov 15 15:32:59.730 [err] crypto error while Writing identity key: result too small (in UI routines:UI_set_result_ex)
Nov 15 15:32:59.730 [err] crypto error while Writing identity key: processing error (in UI routines:UI_process)
Nov 15 15:32:59.730 [err] crypto error while Writing identity key: problems getting password (in PEM routines:PEM_def_callback)
Nov 15 15:32:59.730 [err] crypto error while Writing identity key: read key (in PEM routines:do_pk8pkey)
```
It seems to me that having an empty pass phrase should work; but if we want it to not work, we should say that as an error message.
(Found by tech-exorcist on #tor)
In fact, I just tried it with short passphrases, and they also fail with these cryptic error messages. So it sounds like maybe we have a secret minimum passphrase length or something?Tor: 0.4.6.x-freezeNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40176Tor 0.4.4.5 and Microsoft Windows 10.0.19041.572 - permanent 100 % load of al...2021-07-09T17:22:52ZRahim RollinsTor 0.4.4.5 and Microsoft Windows 10.0.19041.572 - permanent 100 % load of all cores of Intel Core i7-3770K![Tor_process_monitor](/uploads/504abb4a50ffd90145e4638560c8a733/Tor_process_monitor.png)
The installation was performed in accordance with [this article](https://community.torproject.org/relay/setup/bridge/windows/).
```
tor.exe -f torr...![Tor_process_monitor](/uploads/504abb4a50ffd90145e4638560c8a733/Tor_process_monitor.png)
The installation was performed in accordance with [this article](https://community.torproject.org/relay/setup/bridge/windows/).
```
tor.exe -f torrc
13:16:05.406 [notice] Tor 0.4.4.5 (git-24e808e946e741d0) running on Windows 8 [or later] with Libevent 2.1.11-stable, OpenSSL 1.1.1h, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
13:16:05.408 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
13:16:05.432 [notice] Read configuration file "C:\Users\...\AppData\Roaming\tor\torrc".
13:16:05.435 [notice] Based on detected system memory, MaxMemInQueues is set to 2048 MB. You can override this by setting MaxMemInQueues by hand.
13:16:05.436 [notice] Opening Socks listener on 127.0.0.1:9050
13:16:05.436 [notice] Opened Socks listener on 127.0.0.1:9050
13:16:05.437 [notice] Opening OR listener on 0.0.0.0:39331
13:16:05.437 [notice] Opened OR listener on 0.0.0.0:39331
13:16:05.437 [notice] Opening Extended OR listener on 127.0.0.1:0
13:16:05.437 [notice] Extended OR listener listening on port 65332.
13:16:05.437 [notice] Opened Extended OR listener on 127.0.0.1:65332
```
Ports forwarded on the router, they passed the [test](https://bridges.torproject.org/scan/). There is almost no traffic. Left it overnight - in the morning the process is still fully using the processor. While this process is running, it is uncomfortable to work on a computer. Is this normal behavior?
I have not gone here for a few similar posts (#24857 #25461 #30187 ). But I do not know to what extent they are caused by the same reasons as mine.https://gitlab.torproject.org/tpo/core/tor/-/issues/40174tracing-instrumentation-usdt fails to build: error: use of undeclared identif...2022-07-07T00:48:31Zyurivicttracing-instrumentation-usdt fails to build: error: use of undeclared identifier 'tor_circuit'```
src/core/or/circuitlist.c:571:13: error: use of undeclared identifier 'tor_circuit'
tor_trace(TR_SUBSYS(circuit), TR_EV(change_state), circ, circ->state, state);
^
./src/lib/trace/events.h:45:25: note: expanded from mac...```
src/core/or/circuitlist.c:571:13: error: use of undeclared identifier 'tor_circuit'
tor_trace(TR_SUBSYS(circuit), TR_EV(change_state), circ, circ->state, state);
^
./src/lib/trace/events.h:45:25: note: expanded from macro 'TR_SUBSYS'
#define TR_SUBSYS(name) tor_ ## name
^
<scratch space>:130:1: note: expanded from here
tor_circuit
^
src/core/or/circuitlist.c:571:39: error: use of undeclared identifier 'change_state'
tor_trace(TR_SUBSYS(circuit), TR_EV(change_state), circ, circ->state, state);
^
src/core/or/circuitbuild.c:503:3: warning: implicit declaration of function 'STAP_PROBEV' is invalid in C99 [-Wimplicit-function-declaration]
tor_trace(TR_SUBSYS(circuit), TR_EV(establish), circ);
^
./src/lib/trace/events.h:53:5: src/core/or/circuitlist.c:1086:3: warning: implicit declaration of function 'STAP_PROBEV' is invalid in C99 [-Wimplicit-function-declaration]
tor_trace(TR_SUBSYS(circuit), TR_EV(new_origin), circ);
^
```
^
0.4.5.1-alpha on FreeBSD 12.2
Additionally, the file doc/HACKING/Tracing.md mentioned in the changelog https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.4.5.1-alpha doesn't exist.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40173tracing-instrumentation-lttng doesn't build: 'core/or/lttng_circuit.inc' file...2022-07-07T00:48:31Zyurivicttracing-instrumentation-lttng doesn't build: 'core/or/lttng_circuit.inc' file not found```
In file included from src/core/or/circuitlist.c:68:
./src/core/or/trace_probes_circuit.h:18:10: fatal error: 'core/or/lttng_circuit.inc' file not found
#include "core/or/lttng_circuit.inc"
```
0.4.5.1-alpha on FreeBSD 12.2```
In file included from src/core/or/circuitlist.c:68:
./src/core/or/trace_probes_circuit.h:18:10: fatal error: 'core/or/lttng_circuit.inc' file not found
#include "core/or/lttng_circuit.inc"
```
0.4.5.1-alpha on FreeBSD 12.2Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40172Build failure on macOS on master2021-07-09T17:30:28ZMatthew FinkelBuild failure on macOS on masterIn tpo/applications/tor-browser-build#40139 we documented that Tor Browser Nightly build for macOS is failing when linking tor using `master`. This began failing on 24 or 25 October. I haven't bisected which tor commit (or build change) ...In tpo/applications/tor-browser-build#40139 we documented that Tor Browser Nightly build for macOS is failing when linking tor using `master`. This began failing on 24 or 25 October. I haven't bisected which tor commit (or build change) is causing this. Attached is the latest build log when building commit df1637600469 (tip of master, at build time).
[tor-osx-x86_64.log](/uploads/f83b8ec1bc057c5cd7f8774936b35aa5/tor-osx-x86_64.log)Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40167ExitNodes not respected on all websites2022-07-07T00:48:31ZwhatthephilExitNodes not respected on all websitesI described this issue here:
https://tor.stackexchange.com/questions/21671/exitnodes-not-respected-on-particular-website
ExitNodes works for me on most websites but doesn't on this one website. It used to work fine until I updated Tor t...I described this issue here:
https://tor.stackexchange.com/questions/21671/exitnodes-not-respected-on-particular-website
ExitNodes works for me on most websites but doesn't on this one website. It used to work fine until I updated Tor to version 10.0.1. I tried version 10.5 and have the same issue.Tor: 0.4.5.x-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://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/40124Incorrect key ID type used in some ed25519 certificates2022-07-07T00:48:31ZNick MathewsonIncorrect key ID type used in some ed25519 certificatesIn `cert-spec.txt` we specify several possible values for the CERT_KEY_TYPE field, in section A.4. But we don't actually use those: everywhere that we call `tor_cert_sign_impl()` , signed_key type is set to `SIGNED_KEY_TYPE_ED25519`.
...In `cert-spec.txt` we specify several possible values for the CERT_KEY_TYPE field, in section A.4. But we don't actually use those: everywhere that we call `tor_cert_sign_impl()` , signed_key type is set to `SIGNED_KEY_TYPE_ED25519`.
We should adjust the spec to clarify that current tor implementations behave, and (assuming it won't introduce compatibility issue) adjust Tor relay behavior to conform to the spec. We should probably leave onion service behavior alone.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/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/40078Potential consensus divergence from Ed25519 edge cases2022-07-07T00:48:31ZhdevalencePotential consensus divergence from Ed25519 edge casesEd25519 poses risks in consensus-critical applications, because (a) the spec does not require that implementations agree on whether signatures are valid and (b) in practice, implementations differ from the spec and from each other.
In t...Ed25519 poses risks in consensus-critical applications, because (a) the spec does not require that implementations agree on whether signatures are valid and (b) in practice, implementations differ from the spec and from each other.
In the context of working to address this issue in Zcash (resulting in [ZIP215]), I created a set of 196 test vectors, consisting of hex-encoded (public key, signature) pairs on the message `b"Zcash"`. Running these test vectors across various other Ed25519 implementations reveals a wide divergence in behaviour (see [1] [2] for additional context).
From a quick look at the Tor source and some tips from Teor, it looks like Tor has four different verification codepaths: ref10 `open`, ref10 `open_batch`, donna `open`, and donna `open_batch`. But I'm not entirely sure whether these are all used, because that requires a deeper knowledge of the codebase than I have.
The test vectors can be found in C-friendly format (thanks to Patrick Steuer) here: https://github.com/p-steuer/ossl-eddsa-tests
[ZIP215]: https://zips.z.cash/zip-0215
[1]: https://github.com/informalsystems/tendermint-rs/issues/355
[2]: https://github.com/golang/go/issues/40478#issuecomment-666043072https://gitlab.torproject.org/tpo/core/tor/-/issues/40077CI broken in 035/042/043/044 because of stem failure2022-06-17T13:04:20ZGeorge KadianakisCI broken in 035/042/043/044 because of stem failure```
FAIL: test_get_listeners
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/travis/build/torproject/tor/stem/test/require.py", line 75, in wrapped
return func(s...```
FAIL: test_get_listeners
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/travis/build/torproject/tor/stem/test/require.py", line 75, in wrapped
return func(self, *args, **kwargs)
File "/home/travis/build/torproject/tor/stem/stem/util/test_tools.py", line 701, in wrapper
result = loop.run_until_complete(func(*args, **kwargs))
File "/usr/lib/python3.6/asyncio/base_events.py", line 484, in run_until_complete
return future.result()
File "/home/travis/build/torproject/tor/stem/test/integ/control/controller.py", line 976, in test_get_listeners
self.assertEqual([('0.0.0.0', test.runner.ORPORT), ('::', test.runner.ORPORT)], await controller.get_listeners(Listener.OR))
AssertionError: Lists differ: [('0.0.0.0', 1113), ('::', 1113)] != [('0.0.0.0', 1113)]
First list contains 1 additional elements.
First extra element 1:
('::', 1113)
- [('0.0.0.0', 1113), ('::', 1113)]
+ [('0.0.0.0', 1113)]
```
Looking at https://travis-ci.org/github/torproject/tor/builds it seems like 035/042/043/044 builds have been broken for a while.
Seems like https://travis-ci.org/github/torproject/tor/builds/711107611 has been the last 043 build that succeeded, and https://travis-ci.org/github/torproject/tor/builds/711107611 is the one that failed after it.https://gitlab.torproject.org/tpo/core/tor/-/issues/40076Assertion buf->tail failed in buf_assert_ok at src/lib/buf/buffers.c:9192021-02-05T21:03:36ZDimitris ApostolouAssertion buf->tail failed in buf_assert_ok at src/lib/buf/buffers.c:919Latest master on macOS 10.15.6
```
Jul 30 09:50:12.000 [notice] Bootstrapped 100% (done): Done
Jul 30 09:50:13.000 [err] tor_assertion_failed_: Bug: src/lib/buf/buffers.c:919: buf_assert_ok: Assertion buf->tail failed; aborting. (on Tor...Latest master on macOS 10.15.6
```
Jul 30 09:50:12.000 [notice] Bootstrapped 100% (done): Done
Jul 30 09:50:13.000 [err] tor_assertion_failed_: Bug: src/lib/buf/buffers.c:919: buf_assert_ok: Assertion buf->tail failed; aborting. (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: Tor 0.4.5.0-alpha-dev (git-9164d7c75e619182): Assertion buf->tail failed in buf_assert_ok at src/lib/buf/buffers.c:919: . Stack trace: (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 0 tor 0x000000010c69dbd9 log_backtrace_impl + 89 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 1 tor 0x000000010c699a92 tor_assertion_failed_ + 322 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 2 tor 0x000000010c675d6f buf_assert_ok + 495 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 3 tor 0x000000010c4e3d7c assert_connection_ok + 220 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 4 tor 0x000000010c4eecc6 conn_read_callback + 326 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 5 libevent-2.1.7.dylib 0x000000010ca0bfde event_process_active_single_queue + 1186 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 6 libevent-2.1.7.dylib 0x000000010ca08ddb event_base_loop + 1174 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 7 tor 0x000000010c4f1115 do_main_loop + 309 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 8 tor 0x000000010c623be8 tor_run_main + 296 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 9 tor 0x000000010c542f1d tor_main + 125 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 10 tor 0x000000010c4de01b main + 27 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
Jul 30 09:50:13.000 [err] Bug: 11 libdyld.dylib 0x00007fff67dd5cc9 start + 1 (on Tor 0.4.5.0-alpha-dev 9164d7c75e619182)
```Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40073Bug: Tor 0.4.4.3-alpha: Assertion new_conn failed in retry_all_listeners at s...2022-07-07T00:48:30ZtoralfBug: Tor 0.4.4.3-alpha: Assertion new_conn failed in retry_all_listeners at src/core/mainloop/connection.c:3047I changed the torrc from
```
DirPort 80
ORPort 443
```
to
```
DirPort 5.9.158.75:80
ORPort 5.9.158.75:443
```
and runa "rc-service tor reload" hera at a hardened stable Gentoo Linux with sandboxing and got a
```
Jul 28 20:30:52.000 [n...I changed the torrc from
```
DirPort 80
ORPort 443
```
to
```
DirPort 5.9.158.75:80
ORPort 5.9.158.75:443
```
and runa "rc-service tor reload" hera at a hardened stable Gentoo Linux with sandboxing and got a
```
Jul 28 20:30:52.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jul 28 20:30:52.000 [notice] Read configuration file "/etc/tor/torrc".
Jul 28 20:30:52.000 [notice] Processing configuration path "/etc/tor/torrc.d/" at recursion level 1.
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//00_common".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//20_exit_flag".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//40_reject".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//80_accept".
Jul 28 20:30:52.000 [notice] Including configuration file "/etc/tor/torrc.d//90_reject_all".
Jul 28 20:30:52.000 [notice] Opening Directory listener on 5.9.158.75:80
Jul 28 20:30:52.000 [warn] Could not bind to 5.9.158.75:80: Permission denied
Jul 28 20:30:52.000 [err] tor_assertion_failed_(): Bug: src/core/mainloop/connection.c:3047: retry_all_listeners: Assertion new_conn failed; aborting. (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: Tor 0.4.4.3-alpha: Assertion new_conn failed in retry_all_listeners at src/core/mainloop/connection.c:3047: . Stack trace: (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(log_backtrace_impl+0x59) [0x557166a32c19] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x150) [0x557166a2de10] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(retry_all_listeners+0x671) [0x55716689fac1] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(set_options+0xa48) [0x5571669ab908] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(+0x1776a0) [0x5571669ac6a0] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(options_init_from_string+0x119) [0x5571669ac8f9] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(options_init_from_torrc+0x372) [0x5571669acf12] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(+0x5d444) [0x557166892444] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/lib64/libevent-2.1.so.7(+0x21c86) [0x7f7a42484c86] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/lib64/libevent-2.1.so.7(event_base_loop+0x57f) [0x7f7a4248596f] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(do_main_loop+0xdd) [0x5571668a728d] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(tor_run_main+0x855) [0x557166893fa5] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(tor_main+0x46) [0x557166892176] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(main+0x19) [0x557166891d49] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7f7a41d26e2b] (on Tor 0.4.4.3-alpha )
Jul 28 20:30:52.000 [err] Bug: /usr/bin/tor(_start+0x2a) [0x557166891d9a] (on Tor 0.4.4.3-alpha )
```
Tor should IMO reject the config change in such a case, or?Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/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/40071Bug: Bridge obfs4 0.4.5.0-alpha-dev rebuilding descriptor (source: METHOD=NON...2021-07-09T17:30:28ZLX1Bug: Bridge obfs4 0.4.5.0-alpha-dev rebuilding descriptor (source: METHOD=NONE) | Don't know my address while generating descriptor**syslog**:
Self-testing indicates your ORPort xxxxxxx:443 is reachable from the outside. Excellent. Publishing server descriptor.
THEN:
Our IP Address has changed from xxxxxxx to ???; rebuilding descriptor (source: METHOD=NONE).
---
He...**syslog**:
Self-testing indicates your ORPort xxxxxxx:443 is reachable from the outside. Excellent. Publishing server descriptor.
THEN:
Our IP Address has changed from xxxxxxx to ???; rebuilding descriptor (source: METHOD=NONE).
---
Hello. **After update alpha dev**:
> log: "Don't know my address while generating descriptor"
> https://metrics.torproject.org/rs.html#search/agileresearchlab but from the same location stable relay runs normally
I have 2 relays alpha/stable in the same location / 1 fix IP.
This happened after the update, only alpha bridge, stable bridge running normally.
Until then, everything was normal > 1 IP == 2x bridge obfs4.
OS: Debian
I provide alpha just for development research primarily..![obfs4_0.4.5.0-alpha-dev_rebuilding_descriptor](/uploads/97b4a23f12f8b13a4807fc3949e3177b/obfs4_0.4.5.0-alpha-dev_rebuilding_descriptor.jpg)
![_source__METHOD_NONE_](/uploads/8cb0281c7956df60fb0eaf5d84bf63d4/_source__METHOD_NONE_.jpg)Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org