Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2024-01-30T16:07:48Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40661Do phase 3 of proposal 2892024-01-30T16:07:48ZGeorg KoppenDo phase 3 of proposal 289In [prop#289](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/289-authenticated-sendmes.txt) we included a deployment timeline. Currently we are at Phase 2 and Phase 3 contains the following:
```
This phase ...In [prop#289](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/289-authenticated-sendmes.txt) we included a deployment timeline. Currently we are at Phase 2 and Phase 3 contains the following:
```
This phase will effectively exit() all tor not supporting
"FlowCtrl=1". The earliest date we can do that is when all versions
not supporting v1 are EOL.
According to our release schedule[4], this can happen when our latest
LTS (0.3.5) goes EOL that is on Feb 1st, 2022.
```
We are past Feb 1st, 2022 and 0.3.5.x is gone for good for a while. Let's get to Phase 3 for the next major release at least then.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40660"Unknown option ''" log message is confusing2022-10-24T20:48:26ZJeremyRand"Unknown option ''" log message is confusing### Summary
I recently upgraded a machine that runs a `tor` service; after a reboot, the `tor` service immediately fails with the log message "[warn] Failed to parse/validate config: Unknown option ''. Failing." This error message is ...### Summary
I recently upgraded a machine that runs a `tor` service; after a reboot, the `tor` service immediately fails with the log message "[warn] Failed to parse/validate config: Unknown option ''. Failing." This error message is confusing, as I initially interpreted it as indicating that empty lines are no longer permitted in `torrc`, which I was just told on IRC is not the case. It would be nice if this message was a bit more helpful in explaining what went wrong.
(Also, as this error has taken down some onion services I run, and I don't know how to fix it, I would appreciate a suggestion on what this log error means even if it's not fixed quickly in the source code.)
### Steps to reproduce:
I have no idea what I did to trigger this, other than installing `apt` upgrades on the machine where it happened. I did update the `torrc` config about 30 minutes before upgrading, but I had already restarted the `tor` service after updating `torrc` and it seemed fine then.
### What is the current bug behavior?
The message is "[warn] Failed to parse/validate config: Unknown option ''. Failing."
### What is the expected behavior?
The message should either say that empty lines are prohibited if that's the case (I believe it is not), or otherwise give some explanation of where the empty string came from and what's supposed to be there instead.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
- 0.4.5.10.
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
- Whonix-Gateway 16 (morphed from Debian Bullseye) on ppc64le.
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
- Distro morphing via `apt`.
### Relevant logs and/or screenshots
~~~
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.133 [notice] Tor 0.4.5.10 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5
.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.133 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/downlo
ad/download#warning
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.133 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.134 [notice] Read configuration file "/etc/tor/torrc".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.142 [notice] Processing configuration path "/etc/torrc.d/*.conf" at recursion level 1.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/60_network.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/65_gateway.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/65_leak_tests.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/70_workstation.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Processing configuration path "/usr/share/tor/tor-service-defaults-torrc.anondist" at recursion l
evel 2.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/usr/share/tor/tor-service-defaults-torrc.anondist".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/95_whonix.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Processing configuration path "/usr/local/etc/torrc.d/" at recursion level 2.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/usr/local/etc/torrc.d//40_tor_control_panel.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/usr/local/etc/torrc.d//50_user.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.157 [warn] Option 'DisableNetwork' used more than once; all but the last value will be ignored.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.164 [warn] Failed to parse/validate config: Unknown option ''. Failing.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.164 [err] Reading config failed--see warnings above.
~~~
### Possible fixes
No idea.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40659"No more HSDir available to query" log message is confusing2024-02-24T21:53:25ZJeremyRand"No more HSDir available to query" log message is confusing### Summary
The "No more HSDir available to query" log message does not make it clear whether the problem is on the client's end, the onion's end, or some other network issue. This makes it harder for the user to understand what they s...### Summary
The "No more HSDir available to query" log message does not make it clear whether the problem is on the client's end, the onion's end, or some other network issue. This makes it harder for the user to understand what they should do about it.
### Steps to reproduce:
No idea how to reproduce this log message; it happened for a few hours when the Debian apt onion went down on 2022 August 5, and has not occurred since.
### What is the current bug behavior?
The log message is "No more HSDir available to query".
### What is the expected behavior?
The log message should be along the lines of "No more HSDir available to query; probably this means the onion service went away" according to @arma on IRC (see #tor logs from 2022 August 5).
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
- 982c50401c5e9bde6a1c3ef4bf7a9019e007ab03.
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
- Debian Bullseye (with a few irrelevant packages pulled in from other Debian suites).
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
- Bug is present in both Debian Bullseye's `apt` package and latest Git source code from Tor Project.
### Relevant logs and/or screenshots
N/A.
### Possible fixes
Looks like this line should be amended: http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/core/tor/-/blob/982c50401c5e9bde6a1c3ef4bf7a9019e007ab03/src/feature/hs/hs_client.c#L89Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40657"This line should not have been reached"2022-11-23T20:52:09Zholmesworcester"This line should not have been reached"### Summary
We are using Tor in Quiet (tryquiet.org) and see a a bunch of lines that say `[warn] Bug: ...` and a line that says `This line should not have been reached` in our logs.
### Steps to reproduce:
This happens often but I'm...### Summary
We are using Tor in Quiet (tryquiet.org) and see a a bunch of lines that say `[warn] Bug: ...` and a line that says `This line should not have been reached` in our logs.
### Steps to reproduce:
This happens often but I'm not sure it happens always.
### What is the current bug behavior?
Tor seems to be working fine, but we see the following in our logs:
```
backend:tor Aug 09 11:04:22.000 [warn] tor_bug_occurred_(): Bug: src/core/or/reasons.c:498: end_reason_to_http_connect_response_line: This line should not have been reached. (on Tor 0.4.7.7 929a90a24fd63b44)
```
### What is the expected behavior?
Presumably we should not see this.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure. **Tor 0.4.7.7**
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc. **Debian GNU/Linux Bullseye running on ChromeOS VM** (but we've seen it on Ubuntu too)
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc. **Binary from TorBrowser**
### Relevant logs and/or screenshots
[logs-tor.txt](/uploads/72b4353b29e02ef6a58772db3f33f650/logs-tor.txt)
### Possible fixesTor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40653Is it useful turn on "keep alive" for Tor SOCKS5 TCP connection?2022-10-24T20:48:23ZmolnardIs it useful turn on "keep alive" for Tor SOCKS5 TCP connection?
Wasabi Wallet application connects to the [Tor SOCKS5](https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt) endpoint ([code](https://github.com/zkSNACKs/WalletWasabi/blob/13fdc1566b626ac2dc56c33f0eb707bcab04e55b/WalletWa...
Wasabi Wallet application connects to the [Tor SOCKS5](https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt) endpoint ([code](https://github.com/zkSNACKs/WalletWasabi/blob/13fdc1566b626ac2dc56c33f0eb707bcab04e55b/WalletWasabi/Tor/Socks5/TorTcpConnectionFactory.cs#L77-L93)) and it specifies various "keep alive" options for that socket connections. Note that the TCP connections connect the application and Tor both of which runs on the same machine and under the same user.
**Question**
Is it necessary to specify that keep-alive options? Is it recommended? Is it useless?
**Version**
we use the latest released Tor 0.4.7.8.
_The question asked here as well_
https://tor.stackexchange.com/questions/23258/is-it-useful-turn-on-keep-alive-for-tor-socks5-tcp-connectionhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40650The vanguards packages are outdated compared to github's one.2022-10-24T20:51:10ZcypherpunksThe vanguards packages are outdated compared to github's one.I have installed `apt install vanguards` and many configuration options are missing, compared to github's one. There is another identifiable problem. The package's configuration file has `num_layer2_guards = 3` but github's config exampl...I have installed `apt install vanguards` and many configuration options are missing, compared to github's one. There is another identifiable problem. The package's configuration file has `num_layer2_guards = 3` but github's config example file says `num_layer2_guards = 4`. This allows an adversary to identify the version. PLaese publish the new version.https://gitlab.torproject.org/tpo/core/tor/-/issues/40640Tor does not connect/bootstrap with Bridge and no microdescriptors2022-10-24T20:48:19ZValdikSSTor does not connect/bootstrap with Bridge and no microdescriptors### Summary
With UseMicrodescriptors set to 0, it is not possible to connect to the network over Bridge.
The connecting process is stuck at:
`Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits`
### Step...### Summary
With UseMicrodescriptors set to 0, it is not possible to connect to the network over Bridge.
The connecting process is stuck at:
`Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits`
### Steps to reproduce:
1. Configure any Bridge running new versions of Tor and set UseMicrodescriptors 0
2. Try to connect to the network
### What is the current bug behavior?
```
Jul 11 01:53:06.000 [notice] Starting with guard context "bridges"
Jul 11 01:53:06.000 [notice] Delaying directory fetches: No running bridges
Jul 11 01:53:07.000 [notice] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
Jul 11 01:53:07.000 [notice] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
Jul 11 01:53:07.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Jul 11 01:53:07.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Jul 11 01:53:08.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Jul 11 01:53:08.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Jul 11 01:53:08.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Jul 11 01:53:08.000 [notice] Bridge 'Init6TorBridge' has both an IPv4 and an IPv6 address. Will prefer using its IPv4 address (65.21.85.99:8088) based on the configured Bridge address.
Jul 11 01:53:08.000 [notice] new bridge descriptor 'Init6TorBridge' (fresh): $7F6051103D00F6E6615C5C8D92C4B648B32331D3~Init6TorBridge [bbnD2WacA0q3prAx6Lzt946bHD113wVkG4RCjcQFT7s] at 65.21.85.99 and [2a01:4f9:3a:271f:3::66]
Jul 11 01:53:08.000 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
Jul 11 01:53:08.000 [notice] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
Jul 11 01:53:08.000 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
Jul 11 01:53:16.000 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.
Jul 11 01:53:20.000 [notice] Bootstrapped 56% (loading_descriptors): Loading relay descriptors
Jul 11 01:53:20.000 [notice] Bootstrapped 62% (loading_descriptors): Loading relay descriptors
Jul 11 01:53:21.000 [notice] Bootstrapped 69% (loading_descriptors): Loading relay descriptors
Jul 11 01:53:21.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
```
### What is the expected behavior?
Tor connects to the network
### Environment
Version: 0.4.7.8
OS: Linux, self-compiled. Also tried on Fedora 35 with 0.4.6.9.https://gitlab.torproject.org/tpo/core/tor/-/issues/40636reports that relays not obeying DoSConnectionMaxConcurrentCount2023-06-15T10:31:28ZRoger Dingledinereports that relays not obeying DoSConnectionMaxConcurrentCounttoralf and steinex and others on irc report that currently their Tor relays have many dozens of IP addresses that have more than 50 concurrent connections open to their relay.
This is surprising, since we have set
```
DoSConnectionEnabl...toralf and steinex and others on irc report that currently their Tor relays have many dozens of IP addresses that have more than 50 concurrent connections open to their relay.
This is surprising, since we have set
```
DoSConnectionEnabled=1 DoSConnectionMaxConcurrentCount=50
```
in the consensus.
Maybe there is a bug?https://gitlab.torproject.org/tpo/core/tor/-/issues/40633ADD_ONION command returns 512 Bad arguments when space present in TARGET Port...2022-10-24T20:48:15Z05nelsonmADD_ONION command returns 512 Bad arguments when space present in TARGET Port unix path### Summary
Attempting to add a new onion address over Tor's control port via `ADD_ONION` with a target port for a unix socket. If the path of that unix socket contains a space, Tor returns `512 Bad arguments to ADD_ONION: Cannot parse k...### Summary
Attempting to add a new onion address over Tor's control port via `ADD_ONION` with a target port for a unix socket. If the path of that unix socket contains a space, Tor returns `512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)`
The path cannot be quoted like with `SET_CONF` or setting the `HiddenServicePort` in the config. (eg: `unix:"/some/path/with space/hs.sock"`)
### What is the current bug behavior?
`ADD_ONION` command does not accept unix sockets that contain a space in the path.
### What is the expected behavior?
`ADD_ONION` should accept quoted path for unix socket as the TARGET port, the same way it does for `SET_CONF` and in the tor config file.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
`Tor 0.4.7.8 (git-7528524aee3ffe3c) running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1o, Zlib 1.2.11, Liblzma N/A, Libzstd N/A and Glibc 2.33 as libc.`
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
`Pop!_OS 22.04 LTS`
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
Tor binaries are from `tor-browser-build`, running via Jvm using [Kotlin Multiplatform Tor](https://github.com/05nelsonm/kmp-tor)
### Relevant logs and/or screenshots
Succeeds only when there is no space in the path
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port=8764,unix:/tmp/junit7656060516802870873/torservice/data/test_hs.sock
D/<< 250-ServiceID=zahvtr2ytdpcvwqwu5iexxny56bprbc24d54gnfly2mmakszhextcwqd
D/<< 250-PrivateKey=ED25519-V3:EC2Vmd4EDlOtsHIiRjWCJBwzFn8f9vESjICbOvr6sUlPCBAPiWejikz5dQvyqvy4cHml/w6j5d8Xe+UN52YioQ==
D/<< 250 OK
```
Failure when space present
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port=8764,unix:/tmp/junit1395906562298175606/tor service/data/test_hs.sock
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
Does not accept a quoted path like other controller + config declarations do (ex: `unix:"/pa th/to/hs.sock"`)
Multiple attempts to quote the path to see what Tor would accept
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port=8764,unix:"/tmp/junit11141792629624884881/tor service/data/test_hs.sock"
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port=8764,"unix:\"/tmp/junit9907345219862884922/tor service/data/test_hs.sock\""
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port=8764,unix:/tmp/junit8276306503427149359/'tor service'/data/test_hs.sock
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port=8764,unix:/tmp/junit3639204659535652534/tor\ service/data/test_hs.sock
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port="8764,unix:/tmp/junit10022844120041534159/tor service/data/test_hs.sock"
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port="8764 unix:/tmp/junit5623947952132400600/tor service/data/test_hs.sock"
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port="8764 unix:\"/tmp/junit7600073482601005748/tor service/data/test_hs.sock\""
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port="8764,unix:\"/tmp/junit2071402153395563988/tor service/data/test_hs.sock\""
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port=8764,unix:/tmp/junit1872035082845200589/"tor service"/data/test_hs.sock
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port=8764,unix:/tmp/junit4651827787803341153/\"tor service\"/data/test_hs.sock
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
```
D/>> ADD_ONION NEW:ED25519-V3 Flags=MaxStreamsCloseCircuit MaxStreams=4 Port=8764,unix:/tmp/junit14411247957552193815/\'tor service\'/data/test_hs.sock
D/<< 512 Bad arguments to ADD_ONION: Cannot parse keyword argument(s)
```
### Possible fixes
Look for a quoted unix socket path and take argument between quoteshttps://gitlab.torproject.org/tpo/core/tor/-/issues/40632torify fails: [socks5] Resolve destination buffer too small (in socks5_recv_r...2022-10-24T20:48:16Zyurivicttorify fails: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:701)This command fails:
```
$ torify ssh beefy18.nyi.freebsd.org
1655953858 ERROR torsocks[51381]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:701)
ssh: Could not resolve hostname beefy18.nyi.fre...This command fails:
```
$ torify ssh beefy18.nyi.freebsd.org
1655953858 ERROR torsocks[51381]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:701)
ssh: Could not resolve hostname beefy18.nyi.freebsd.org: Non-recoverable failure in name resolution
```
tor-0.4.7.8
FreeBSD 13.1https://gitlab.torproject.org/tpo/core/tor/-/issues/40627Consider investigating The Maze2022-07-11T19:38:41ZMike PerryConsider investigating The MazeDuring the congestion control and vanguards-lite deployments in 0.4.7, we managed to disturb some balrogs in Tor's circuit construction maze: https://gitlab.torproject.org/tpo/core/tor/-/issues/40612 and https://gitlab.torproject.org/tpo...During the congestion control and vanguards-lite deployments in 0.4.7, we managed to disturb some balrogs in Tor's circuit construction maze: https://gitlab.torproject.org/tpo/core/tor/-/issues/40612 and https://gitlab.torproject.org/tpo/core/tor/-/issues/40603.
In the first case, The Maze was managing to build 4 hop exit circuits somehow. This should not be happening, and can degrade performance if these circuits are used for website activity. Very oddly, these circuits managed to get built primarily when Tor is being used only as a Bridge, with no direct client or onion service activity.
In the second case, Tor was failing to find a valid 2nd hop for its path, briefly, during startup.
A brave soul could try to investigate these. This is not worth a ton of effort, but perhaps during conflux or UDP implementation we will uncover the secrets of whatever trap doors there are in the Maze that cause this activity.
To do so, we will have to use Info logs to keep an eye out for those two logs, since they have been demoted. This ticket is to remind us to at least check if we can get them to happen in sims/testing.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40624not helpful warning Sudden increase in circuit RTT (1557538 vs 91), likely du...2022-10-24T20:48:03Ztoralfnot helpful warning Sudden increase in circuit RTT (1557538 vs 91), likely due to clock jump.I've two relays running at a same dedicated hardware under a stable hardened Gentoo:
```
$ tor --version
Tor version 0.4.8.0-alpha-dev (git-b733f9d6ace63c71).
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1o, Zlib 1.2....I've two relays running at a same dedicated hardware under a stable hardened Gentoo:
```
$ tor --version
Tor version 0.4.8.0-alpha-dev (git-b733f9d6ace63c71).
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1o, Zlib 1.2.12, Liblzma 5.2.5, Libzstd 1.5.2 and Glibc 2.34 as libc.
Tor compiled with GCC version 11.3.0
```
One of them suddenly spewed at 04:12 UTC
```
Sudden increase in circuit RTT (1557538 vs 91), likely due to clock jump.
```
following by
```
Our clock has been stalled for the entire lifetime of a circuit. Performance may be sub-optimal. [164 similar message(s) suppressed in last 360 seconds]
```
every 5 or 6 minutes since that (the time period oscillates between 300 and 360 seconds of that message).
The other relay with same version at the same ip is running flawlessly.https://gitlab.torproject.org/tpo/core/tor/-/issues/40622Connection DDoS defenses never applied to DirPort so dir auths still impacted2023-09-11T19:14:14ZRoger DingledineConnection DDoS defenses never applied to DirPort so dir auths still impactedBack in the connection DDoS problems a year or two back, I hacked up a defense which counted total connections from a given IP address to either my ORPort or my DirPort, and refused future connections for a while if the connection attemp...Back in the connection DDoS problems a year or two back, I hacked up a defense which counted total connections from a given IP address to either my ORPort or my DirPort, and refused future connections for a while if the connection attempt count trips some token-bucket-style threshold.
That threshold has tripped a lot lately and I have been saving myself a lot of connections on moria1 (along with the accompanying bandwidth, memory bloat, upstream problems with connection tables, etc). Here is the latest stat line after 43 days:
```
Jun 06 19:29:31.165 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 749704 connections closed because concurrent, 28222170 connections closed because total. 0 single hop clients refused. 0 INTRODUCE2 rejected.
```
(Yes, I have been turning away 7 to 8 connections per second, continuously, averaged over the last 43 days. Some addresses are super loud and have no notion of back-off.)
Alas, when I looked earlier, the patch that went into actual Tor only considered ORPort connections, and so it doesn't help me because a lot of my overload is on the DirPort.
Double-alas, my patch and the patch that went in are full of conflicts.
So: I have been meaning to reverse engineer the patch that went in to 0.4.6.1-alpha (#40253), and my patch (in my moria1-0460 branch), and figure out what is actually missing, and make a new patch that applies cleanly to a more recent Tor.
That step doesn't fit in my q1-q2 task set though, so I have been meaning to get to it in q3-q4.
But the network is now all using consensus method 32 (for the MiddleOnly flag), so I need to do something sooner.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40618Flood of "Bridge has both an IPv4 and an IPv6 address"2023-05-31T18:44:13ZcypherpunksFlood of "Bridge has both an IPv4 and an IPv6 address"Tor version: 4.7.7.
Several times I got logs like this:
<pre>
[NOTICE] Bridge '[scrubbed by me]' has both an IPv4 and an IPv6 address. Will prefer using its IPv4 address ([scrubbed by me]) based on the configured Bridge address.
</pre>...Tor version: 4.7.7.
Several times I got logs like this:
<pre>
[NOTICE] Bridge '[scrubbed by me]' has both an IPv4 and an IPv6 address. Will prefer using its IPv4 address ([scrubbed by me]) based on the configured Bridge address.
</pre>
really many times (up to 30 for one bridge, more than 100 if counting different bridges together and ignoring heartbeats), with delays of minutes or even seconds - shortest was less than second. Address is the same all the time, obviously.
Maybe this flood is bug on its own. Maybe reason is legitimate, but it should be ratelimited.Tor: 0.4.7.x-post-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40617dirport but no orport triggers assert failure2023-01-10T14:50:11ZRoger Dingledinedirport but no orport triggers assert failure```
% src/app/tor dirport 9030
[...]
May 28 02:49:41.954 [err] tor_assertion_failed_(): Bug: src/lib/crypt_ops/crypto_ed25519.c:658: ed25519_pubkey_copy: Assertion src failed; aborting. (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 ...```
% src/app/tor dirport 9030
[...]
May 28 02:49:41.954 [err] tor_assertion_failed_(): Bug: src/lib/crypt_ops/crypto_ed25519.c:658: ed25519_pubkey_copy: Assertion src failed; aborting. (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: Tor 0.4.8.0-alpha-dev (git-69e3b8bb843aaab6): Assertion src failed in ed25519_pubkey_copy at src/lib/crypt_ops/crypto_ed25519.c:658: . Stack trace: (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(log_backtrace_impl+0x57) [0x559f702dd237] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(tor_assertion_failed_+0x148) [0x559f702e8218] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(ed25519_pubkey_copy+0x94) [0x559f702d0bd4] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(server_onion_keys_new+0x4b) [0x559f70400a1b] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(+0x1ab218) [0x559f703a7218] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(threadpool_new+0x199) [0x559f70414739] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(cpu_init+0x8d) [0x559f703a76ed] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(run_tor_main_loop+0xe3) [0x559f70260683] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(tor_run_main+0x1d5) [0x559f70260bb5] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(tor_main+0x49) [0x559f7025d0d9] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(main+0x19) [0x559f7025ccb9] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7fb309032d0a] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
May 28 02:49:41.955 [err] Bug: src/app/tor(_start+0x2a) [0x559f7025cd0a] (on Tor 0.4.8.0-alpha-dev 69e3b8bb843aaab6)
Aborted
```
I did a git bisect: commit 244444e8b1ac36b works and commit bd2e9a44097ff85 is the first broken one.
I assume it is this line:
```
+ ed25519_pubkey_copy(&keys->my_ed_identity, get_master_identity_key());
```
where the other functions called from server_onion_keys_new() check if there aren't any keys before doing their thing, but this one doesn't.
This commit went into Tor 0.4.7.4-alpha.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40616MiddleNodes does not work2022-06-01T12:53:24ZGitRowinMiddleNodes does not work### Summary
When using the MiddleNodes option, Tor hangs forever during bootstrapping, regardless of what middle relay is picked.
### Steps to reproduce:
1. Add `MiddleNodes <any fingerprint>` to torrc
2. Start Tor
### What is the cu...### Summary
When using the MiddleNodes option, Tor hangs forever during bootstrapping, regardless of what middle relay is picked.
### Steps to reproduce:
1. Add `MiddleNodes <any fingerprint>` to torrc
2. Start Tor
### What is the current bug behavior?
Tor hangs forever during bootstrapping:
```
May 27 17:54:24.000 [notice] Bootstrapped 0% (starting): Starting
May 27 17:54:24.000 [notice] Starting with guard context "default"
May 27 17:54:25.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
May 27 17:54:25.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
May 27 17:54:26.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
May 27 17:54:27.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
May 27 17:54:27.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
May 27 17:54:27.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
May 27 17:54:27.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
May 27 17:54:27.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
May 27 17:54:28.000 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
May 27 17:54:28.000 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
May 27 17:54:28.000 [notice] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
May 27 17:54:28.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/1, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
May 27 17:54:28.000 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
May 27 17:54:29.000 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.
```
### What is the expected behavior?
Tor should start up and create circuits using only the selected middle relay.
### Environment
Tor version 0.4.5.10 installed using apt on Debian GNU/Linux 11 (bullseye).Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40615Confirm Tor Project tor.git package builds are reproducible2023-04-12T15:23:46ZMike PerryConfirm Tor Project tor.git package builds are reproducibleOur deb.torproject.org debs are now built on Gitlab (and possibly our RPMs too?). I believe the deb.torproject.org packages come from https://gitlab.torproject.org/tpo/core/debian/tor/-/pipelines, but @weasel will have to confirm. I am l...Our deb.torproject.org debs are now built on Gitlab (and possibly our RPMs too?). I believe the deb.torproject.org packages come from https://gitlab.torproject.org/tpo/core/debian/tor/-/pipelines, but @weasel will have to confirm. I am less sure where the RPMs come from. @kushal will have to let us know.
We should confirm that these packages are reproducible. If they are based on the Debian build system, I believe they should be. And tor.git itself might be reproducible by default. However, @weasel was not sure if this was the case, and @ahf and I were not either.
It would be a sad day if Gitlab 0day got someone the whole Tor network, and reproducible builds prevent this possibility, and also allow us to check this after-the-fact.
So I am creating this ticket to check reproducibility, and then fix any issues.
I think the best way forward is to export the gitlab runner script into a standard docker container and see if the sha256sums from https://deb.torproject.org/torproject.org/pool/main/t/tor/ match from the resulting debs from said docker container, or even just a build on a random debian machine. But there may be other ways. I know @jnewsome is good at spinning up ephemeral runners, so that could be another route too, but that does not fully eliminate Gitlab from the picture.
If the test build's sha256sums do not match against the ones in https://deb.torproject.org/torproject.org/pool/main/t/tor/, we may want to use @boklm's RBM tool in our gitlab tor.git build runners, to make it reproducible. (RBM is what Tor Browser now uses, to produce reproducible Tor Browser releases.)
Cc: @boklm, @jnewsome, @kushal, @ahf, @dgoulet, @weasel, @anarcat, @lavamindTor: 0.4.7.x-post-stableIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40614Report CPU overload2023-02-07T10:20:22ZAlex XuReport CPU overloadIn http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-03-08-16.59.log.html, it was agreed to drop CPU overload reporting in part on the basis that:
```
17:12:38 <asn> i have no idea how to measure CPU utilization in a multi-pla...In http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-03-08-16.59.log.html, it was agreed to drop CPU overload reporting in part on the basis that:
```
17:12:38 <asn> i have no idea how to measure CPU utilization in a multi-platform way
```
While it's true that there's no cross-platform way to measure CPU utilization, we don't actually want to know the percentage of CPU utilization anyways. Even if we did, it wouldn't be useful: suppose there are 2 CPUs, each at 50% utilization. Is tor overloaded? There's no way to tell using this information: maybe tor is using 50% of one CPU and something else is using 50% of another, so tor is not overloaded; or, maybe tor is pegging one CPU and is being bounced back and forth, so tor is actually overloaded.
What we really want to know is whether tor is bottlenecked by the CPU instead of by the network interface or by other nodes. What this means in the main loop is that normally, when tor goes to check for events, tor would like to block in poll or equivalent for a little while, not constantly be processing event callbacks. If poll always returns immediately, that means that lots of events are queueing up that tor isn't processing expeditiously; in other words, either the CPU is too busy or tor is swapping excessively.
The main problems with implementing this are:
1. how do we actually determine if poll returned "immediately"? a hardcoded duration will incorrectly classify very fast relays (with low duration between FD activation) as overloaded or incorrectly classify very slow relays (with high syscall overhead) as not overloaded or both. In the raw API, I think the best way to do this is to call poll with a timeout of 0, and see if any FDs become active. In libevent, I think the least worst way to do this is to occasionally call event_base_loop with EVLOOP_NONBLOCK, then use a prepare watcher to call event_base_get_num_events with EVENT_BASE_COUNT_ACTIVE. if it is non-zero, record potential overload and continue calling event_base_loop with EVLOOP_NONBLOCK; if it is zero, call event_base_loop without EVLOOP_NONBLOCK. Alternatively, it might be possible to just use the prepare watcher without EVLOOP_NONBLOCK, and check that the number of activated events is "small".
2. how many times does "excessive events" need to happen in order to be considered overloaded? 1? 10? 100? should it be time-based, e.g. we called event_base_loop with EVLOOP_NONBLOCK continuously for 60 seconds and it kept invoking callbacks?https://gitlab.torproject.org/tpo/core/tor/-/issues/40611IPv4-mapped IPV6 addresses fail badly2022-10-24T20:31:53ZJim NewsomeIPv4-mapped IPV6 addresses fail badlyOriginally discovered when debugging signal-cli via torsocks: https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40009#note_2803952
I can now reproduce without torsocks:
The following command, connecting to facebook's ipv6 addres...Originally discovered when debugging signal-cli via torsocks: https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40009#note_2803952
I can now reproduce without torsocks:
The following command, connecting to facebook's ipv6 address via tor, works as expected:
```
$ curl -k -L --preproxy socks5://localhost:9050 https://[2a03:2880:f134:83:face:b00c:0:25de]
```
Without tor, we can also connect to facebook's ipv4 address via ipv6, using a [IPv4-mapped IPv6 address](https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses):
```
$ curl -k -L --preproxy https://[::ffff:31.13.93.35]
```
However if we try to do that using tor, the connection attempt hangs in curl. In the tor log we see it repeatedly trying and failing to build a path:
```
$ curl -k -L --preproxy socks5://localhost:9050 https://[::ffff:31.13.93.35]
```
With tor running as:
```
tor --SocksPort "ip6-localhost:9050 IPv6Traffic" --SocksPort "localhost:9050 IPv6Traffic" --Log "debug" --SafeLogging 0 --ClientUseIPv6 1
```
We get lines like:
```
May 17 15:38:04.000 [info] connection_ap_process_end_not_open(): Address '[::ffff:31.13.93.35]' refused due to 'exit policy failed'. Considering retrying.
May 17 15:38:04.000 [debug] addr_policy_append_reject_addr(): Adding a reject ExitPolicy 'reject ::ffff:31.13.93.35:*'
```
Full tor log: [tor-v6-mapped.log.gz](/uploads/9f9a571aad386aa79a14682c16ac1231/tor-v6-mapped.log.gz)Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40609Poor UX when missing curly brackets in torrc's ExitNodes setting2022-12-16T20:24:03ZviPoor UX when missing curly brackets in torrc's ExitNodes setting### Summary
/etc/tor/torrc with a line like `ExitNodes us` instead of `ExitNodes {us}` is accepted, but fails to bootstrap.
### Steps to reproduce:
1. Edit torrc file: add `ExitNodes` with invalid syntax (omitted curly brackets)
2. S...### Summary
/etc/tor/torrc with a line like `ExitNodes us` instead of `ExitNodes {us}` is accepted, but fails to bootstrap.
### Steps to reproduce:
1. Edit torrc file: add `ExitNodes` with invalid syntax (omitted curly brackets)
2. Start or reload Tor
3. Try to use it.
### What is the current bug behavior?
It starts, sticks at 0% bootstrapping (or logs `Our directory information is no longer up-to-date enough to build circuits: We need more microdescriptors: we have 7057/7057, and can only build 0% of likely paths. (We have 100% of guards bw, 100% of midpoint bw, and 0% of exit bw = 0% of path bw.)` if reloaded), does not work.
### What is the expected behavior?
Tor refuses to read torrc file as invalid, showing the line number of ExitNodes directive, ideally also recongnizing and explaining the mistake.
Alternatively, the bracket-less syntax is considered valid and working and Tor works normally and a line like `ExitNodes us` is applied, just like `ExitNodes {us}`.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
```
Tor version 0.4.7.7.
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
Tor compiled with GCC version 10.2.1
```
- Which operating system are you using? Debian GNU/Linux Bullseye on x86_64.
- Which installation method did you use? Distribution package from bullseye-backports.