Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-06-13T20:47:38Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40806running tor guard/bridge/exit behind layers of nat2023-06-13T20:47:38Zredbearrunning tor guard/bridge/exit behind layers of natThe issue is i can start a node and port is reached by outside but outside ips need uses some intermediate ip to access node. There is some work around ? is possible make something or config on torrc ?The issue is i can start a node and port is reached by outside but outside ips need uses some intermediate ip to access node. There is some work around ? is possible make something or config on torrc ?https://gitlab.torproject.org/tpo/core/tor/-/issues/40807Look for the lib64 directory when using a custom OpenSSL directory2023-06-12T16:28:25ZPier Angelo VendrameLook for the lib64 directory when using a custom OpenSSL directoryFor Tor Browser, we build tor in an old Debian container that has a very old OpenSSL.
So, we also compile OpenSSL and use a custom prefix with `--with-openssl-dir=$openssldir`.
From what I understood (by compiling with `make V=1`), it s...For Tor Browser, we build tor in an old Debian container that has a very old OpenSSL.
So, we also compile OpenSSL and use a custom prefix with `--with-openssl-dir=$openssldir`.
From what I understood (by compiling with `make V=1`), it seems to me that tor's build system tries to use `$openssldir/lib` as a library directory (and IIRC, it falls back to `$openssldir` when it doesn't exist).
However, with OpenSSL 3, the default directory has become `$openssldir/lib64` (at least on Linux amd64).
Linking `$openssldir/lib` to `$openssldir/lib64` seems to solve all the various problems.https://gitlab.torproject.org/tpo/core/tor/-/issues/40809Bring padding machines into sync with Tobias's latest changes2023-06-15T10:31:28ZMike PerryBring padding machines into sync with Tobias's latest changesTobias has added some changes to the padding machines in his latest research: in particular, the padding machine can respond to queue length/congestion signals. I believe there are now also probabilistic transitions (ie https://gitlab.to...Tobias has added some changes to the padding machines in his latest research: in particular, the padding machine can respond to queue length/congestion signals. I believe there are now also probabilistic transitions (ie https://gitlab.torproject.org/tpo/core/tor/-/issues/31636 or https://gitlab.torproject.org/tpo/core/tor/-/issues/31787).
I need to read his latest paper, sync with him, and discuss these things. This will generate new tickets.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40820connection_edge_about_to_close(): Bug: (Harmless.) Edge connection (marked at...2024-03-21T18:27:41Zcomputer_freakconnection_edge_about_to_close(): Bug: (Harmless.) Edge connection (marked at ../src/core/or/circuitlist.c:2713) hasn't sent end yet? (on Tor 0.4.7.13 )```
...
07:55:37.000 [notice] Heartbeat: Tor's uptime is 7 days 18:00 hours, with 71411 circuits open. I've sent 10022.56 GB and received 9786.33 GB. I've received 3866839 connections on IPv4 and 21166 on IPv6. I've made 181900 connectio...```
...
07:55:37.000 [notice] Heartbeat: Tor's uptime is 7 days 18:00 hours, with 71411 circuits open. I've sent 10022.56 GB and received 9786.33 GB. I've received 3866839 connections on IPv4 and 21166 on IPv6. I've made 181900 connections with IPv4 and 56445 with IPv6.
07:55:37.000 [notice] While bootstrapping, fetched this many bytes: 8107 (microdescriptor fetch)
07:55:37.000 [notice] While not bootstrapping, fetched this many bytes: 148937098 (server descriptor fetch); 5760 (server descriptor upload); 12096007 (consensus network-status fetch); 3883848 (microdescriptor fetch)
07:55:37.000 [notice] Circuit handshake stats since last time: 517/517 TAP, 3956544/3973033 NTor.
07:55:37.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 6320 v3 connections; initiated 3 and received 190964 v4 connections; initiated 71807 and received 3613775 v5 connections.
07:55:37.000 [notice] Heartbeat: DoS mitigation since startup: 1037 circuits killed with too many cells, 32767104 circuits rejected, 401 marked addresses, 1 marked addresses for max queue, 172207 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 2185090 INTRODUCE2 rejected.
13:37:58.000 [notice] We're low on memory (cell queues total alloc: 10805520 buffer total alloc: 12886016, tor compress total alloc: 667208970 (zlib: 259584, zstd: 666941450, lzma: 0), rendezvous cache total alloc: 109213998). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
13:37:58.000 [notice] Removed 85978221 bytes by killing 62 circuits; 49010 circuits remain alive. Also killed 0 non-linked directory connections. Killed 3 edge connections
13:37:58.000 [warn] connection_edge_about_to_close(): Bug: (Harmless.) Edge connection (marked at ../src/core/or/circuitlist.c:2713) hasn't sent end yet? (on Tor 0.4.7.13 )
13:37:58.000 [warn] tor_bug_occurred_(): Bug: ../src/core/or/connection_edge.c:1065: connection_edge_about_to_close: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: Tor 0.4.7.13: Line unexpectedly reached at connection_edge_about_to_close at ../src/core/or/connection_edge.c:1065. Stack trace: (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x57) [0x55ba820720e7] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x16b) [0x55ba8207d30b] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(connection_exit_about_to_close+0x1d) [0x55ba8211e4fd] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(+0x6b5ed) [0x55ba81ff65ed] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(+0x6bcfb) [0x55ba81ff6cfb] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.7(+0x23b4f) [0x7fc9eef8db4f] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x52f) [0x7fc9eef8e28f] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x101) [0x55ba81ff86f1] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1e5) [0x55ba81ff3fc5] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(tor_main+0x49) [0x55ba81ff02d9] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x55ba81fefeb9] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7fc9ee828d0a] (on Tor 0.4.7.13 )
13:37:58.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x55ba81feff0a] (on Tor 0.4.7.13 )
13:37:58.000 [warn] connection_edge_about_to_close(): Bug: (Harmless.) Edge connection (marked at ../src/core/or/circuitlist.c:2713) hasn't sent end yet? (on Tor 0.4.7.13 )
13:37:58.000 [warn] connection_edge_about_to_close(): Bug: (Harmless.) Edge connection (marked at ../src/core/or/circuitlist.c:2713) hasn't sent end yet? (on Tor 0.4.7.13 )
13:37:58.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:37:58.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:10.000 [notice] We're low on memory (cell queues total alloc: 15153072 buffer total alloc: 11710464, tor compress total alloc: 664530008 (zlib: 302848, zstd: 664219240, lzma: 0), rendezvous cache total alloc: 109213998). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
13:38:10.000 [notice] Removed 83687644 bytes by killing 17 circuits; 49083 circuits remain alive. Also killed 0 non-linked directory connections. Killed 0 edge connections
13:38:11.000 [notice] We're low on memory (cell queues total alloc: 14386416 buffer total alloc: 12208128, tor compress total alloc: 665847849 (zlib: 259584, zstd: 665580345, lzma: 0), rendezvous cache total alloc: 109213998). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
13:38:11.000 [notice] Removed 88057871 bytes by killing 17 circuits; 49151 circuits remain alive. Also killed 0 non-linked directory connections. Killed 0 edge connections
13:38:11.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:11.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:11.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:11.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:11.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:12.000 [notice] We're low on memory (cell queues total alloc: 13510992 buffer total alloc: 11796480, tor compress total alloc: 665718009 (zlib: 129792, zstd: 665580345, lzma: 0), rendezvous cache total alloc: 109213998). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
13:38:12.000 [notice] Removed 82329467 bytes by killing 14 circuits; 49226 circuits remain alive. Also killed 0 non-linked directory connections. Killed 0 edge connections
13:38:12.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:12.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:12.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:12.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:12.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:12.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:12.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:12.000 [warn] channel_flush_from_first_active_circuit(): Bug: Found a supposedly active circuit with no cells to send. Trying to recover. (on Tor 0.4.7.13 )
13:38:13.000 [notice] We're low on memory (cell queues total alloc: 14437632 buffer total alloc: 12062720, tor compress total alloc: 664356888 (zlib: 129792, zstd: 664219240, lzma: 0), rendezvous cache total alloc: 109213998). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
13:38:13.000 [notice] Removed 81757690 bytes by killing 15 circuits; 49281 circuits remain alive. Also killed 0 non-linked directory connections. Killed 0 edge connections
13:54:30.000 [notice] Sudden decrease in circuit RTT (11 vs 119683), likely due to clock jump.
13:55:37.000 [notice] Heartbeat: Tor's uptime is 8 days 0:00 hours, with 74885 circuits open. I've sent 10349.14 GB and received 10099.50 GB. I've received 3979142 connections on IPv4 and 21891 on IPv6. I've made 187464 connections with IPv4 and 57946 with IPv6.
13:55:37.000 [notice] While bootstrapping, fetched this many bytes: 8107 (microdescriptor fetch)
13:55:37.000 [notice] While not bootstrapping, fetched this many bytes: 154088181 (server descriptor fetch); 5760 (server descriptor upload); 12495772 (consensus network-status fetch); 4020088 (microdescriptor fetch)
13:55:37.000 [notice] Circuit handshake stats since last time: 581/581 TAP, 2997064/3009741 NTor.
13:55:37.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 6720 v3 connections; initiated 3 and received 199738 v4 connections; initiated 73618 and received 3714169 v5 connections.
13:55:37.000 [notice] Heartbeat: DoS mitigation since startup: 1051 circuits killed with too many cells, 33500595 circuits rejected, 404 marked addresses, 1 marked addresses for max queue, 183981 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 2523887 INTRODUCE2 rejected.
...
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40822[warn] Possible replay detected! An INTRODUCE2 cell with the same ENCRYPTED s...2023-08-28T12:28:35ZTimeIsGold[warn] Possible replay detected! An INTRODUCE2 cell with the same ENCRYPTED section was seen 0 seconds ago. Dropping cell.I am running HS using Tor 0.4.7.13 Running on Windows Server and i am using Obfs4 Bridges for my nodes.
i got this messages every day and i don't know what is the problem
`[warn] Possible replay detected! An INTRODUCE2 cell with the sam...I am running HS using Tor 0.4.7.13 Running on Windows Server and i am using Obfs4 Bridges for my nodes.
i got this messages every day and i don't know what is the problem
`[warn] Possible replay detected! An INTRODUCE2 cell with the same ENCRYPTED section was seen 0 seconds ago. Dropping cell.`
`[notice] Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.`https://gitlab.torproject.org/tpo/core/tor/-/issues/40831null pointer dereference if threadpool initialization fails2023-10-08T15:25:20ZAlex Xunull pointer dereference if threadpool initialization fails```
In function 'threadpool_register_reply_event',
inlined from 'cpuworker_init' at src/core/mainloop/cpuworker.c:140:13,
inlined from 'run_tor_main_loop' at src/app/main/main.c:1230:3,
inlined from 'tor_run_main' at src/app/...```
In function 'threadpool_register_reply_event',
inlined from 'cpuworker_init' at src/core/mainloop/cpuworker.c:140:13,
inlined from 'run_tor_main_loop' at src/app/main/main.c:1230:3,
inlined from 'tor_run_main' at src/app/main/main.c:1359:14,
inlined from 'tor_main' at src/feature/api/tor_api.c:166:12,
inlined from 'main' at src/app/main/tor_main.c:32:7:
src/lib/evloop/workqueue.c:631:9: warning: potential null pointer dereference [-Wnull-dereference]
631 | if (tp->reply_event) {
| ^
```
if `threadpool_new` fails, then `tp` will be null. `spawn_func` should not normally fail, and furthermore the result will most likely be a non-exploitable segmentation fault, but it is still technically undefined behavior and should be fixed.Tor: 0.4.9.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40836Update recommended/required protocol lists?2024-01-16T15:38:37ZNick MathewsonUpdate recommended/required protocol lists?We haven't updated the recommended/required protocol lists since 2021, possibly longer. If we mark more protocols as required or recommended, we can more correctly reason about the network.
The protocols that are unconditionally suppor...We haven't updated the recommended/required protocol lists since 2021, possibly longer. If we mark more protocols as required or recommended, we can more correctly reason about the network.
The protocols that are unconditionally supported by 0.4.7.7 (our oldest supported stable) are:
* `Cons=1-2 Desc=1-2 DirCache=2 FlowCtrl=1-2 HSDir=2 HSIntro=4-5 HSRend=1-2 Link=1-5 LinkAuth=3 Microdesc=1-2 Padding=2 Relay=1-4`
The protocols that are unconditionally supported by the most recent Arti are not currently listed anywhere or enforced in Arti. :disappointed: So maybe we should take care of that first?
The protocols that the consensus currently recommends are:
* `recommended-client-protocols Cons=2 Desc=2 DirCache=2 HSDir=2 HSIntro=4 HSRend=2 Link
=4-5 Microdesc=2 Relay=2`
* `recommended-relay-protocols Cons=2 Desc=2 DirCache=2 HSDir=2 HSIntro=4 HSRend=2 Link=4-5 LinkAuth=3 Microdesc=2 Relay=2`
The protocols that the consensus currently requires are:
* `required-client-protocols Cons=2 Desc=2 Link=4 Microdesc=2 Relay=2`
* `required-relay-protocols Cons=2 Desc=2 DirCache=2 HSDir=2 HSIntro=4 HSRend=2 Link=4-5 LinkAuth=3 Microdesc=2 Relay=2`
cc @dgoulet @mikeperryNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40840Prevent outbound cell command flipping2024-02-13T17:00:47ZMike PerryPrevent outbound cell command flippingAs per https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-protocol-info-leaks.txt#L197, the RELAY_EARLY fix did not address the outbound direction.
We can fix this by checking at relays that the cell command field ...As per https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-protocol-info-leaks.txt#L197, the RELAY_EARLY fix did not address the outbound direction.
We can fix this by checking at relays that the cell command field does not switch back and forth between RELAY and RELAY_EARLY. Then, so long as the middle relay is honest, this vector cannot be used as a covert channel between the Guard and the Exit.
This fix should be relatively simple and can be backported, though we should of course test it in shadow.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40847tor 0.4.8.4: compilation error on SunOS / OpenIndiana2023-09-06T00:57:05Zsvschmeltor 0.4.8.4: compilation error on SunOS / OpenIndianaCompiling tor 0.4.8.4 throws the following error.
(Similar to https://gitlab.torproject.org/tpo/core/tor/-/issues/40843 => compilation error on NetBSD)
```
/export/home/svschmel/oi-userland/components/network/tor/tor-0.4.8.4/src/ext/equ...Compiling tor 0.4.8.4 throws the following error.
(Similar to https://gitlab.torproject.org/tpo/core/tor/-/issues/40843 => compilation error on NetBSD)
```
/export/home/svschmel/oi-userland/components/network/tor/tor-0.4.8.4/src/ext/equix/hashx/src/virtual_memory.c: In function 'hashx_vm_alloc_huge':
/export/home/svschmel/oi-userland/components/network/tor/tor-0.4.8.4/src/ext/equix/hashx/src/virtual_memory.c:113:5: error: 'MAP_HUGETLB' undeclared (first use in this function)
113 | | MAP_HUGETLB | MAP_POPULATE, -1, 0);
| ^~~~~~~~~~~
/export/home/svschmel/oi-userland/components/network/tor/tor-0.4.8.4/src/ext/equix/hashx/src/virtual_memory.c:113:5: note: each undeclared identifier is reported only once for each function it appears in
/export/home/svschmel/oi-userland/components/network/tor/tor-0.4.8.4/src/ext/equix/hashx/src/virtual_memory.c:113:19: error: 'MAP_POPULATE' undeclared (first use in this function); did you mean 'MAP_PRIVATE'?
113 | | MAP_HUGETLB | MAP_POPULATE, -1, 0);
| ^~~~~~~~~~~~
| MAP_PRIVATE
make[2]: *** [Makefile:16523: src/ext/equix/hashx/src/libhashx_a-virtual_memory.o] Error 1
make[2]: Leaving directory '/export/home/svschmel/oi-userland/components/network/tor/build/amd64'
make[1]: *** [Makefile:7648: all] Error 2
```
These defines do not exist on SunOS / OpenIndiana
=> https://www.illumos.org/man/2/mmap
I suggest handling SunOS like OpenBSD in file "virtual_memory.c" because the default => the "#else"- tree <= assumes that the underlying OS is a Linux-system.
```
...
#elif defined(__OpenBSD__)
mem = MAP_FAILED; // OpenBSD does not support huge pages
#else
mem = mmap(NULL, bytes, PAGE_READWRITE, MAP_PRIVATE | MAP_ANONYMOUS
| MAP_HUGETLB | MAP_POPULATE, -1, 0);
...
```
With this modification the code can be compiled on SunOS / Openindiana successful.https://gitlab.torproject.org/tpo/core/tor/-/issues/40901Document for the Relay Operator community how to debug relays that are slower...2023-12-19T07:53:56ZAlexander Færøyahf@torproject.orgDocument for the Relay Operator community how to debug relays that are slower than what the operator expectsThis idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more...This idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more|less) memory/crashes (more|less) often/etc. many of these items are hard to give a definitive "yes, the cause of this is X" and it's very time consuming for the Network Team to debug each item individually with the operator.
It would be very useful to have a document in place that informs relay operators about the different situations that may impact performance and how they can get some performance measurements they can then compare to and see if our performance have truly regressed. This can also be used to push MetricsPort to more operators.
We can expand upon the document over time as we discover new ways to do this analysis and/or from feedback from the relay operator community.
This is related to:
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021409.html
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021407.html
This may be relevant to Arti Relay too.
CC @mikeperry for awareness.https://gitlab.torproject.org/tpo/core/tor/-/issues/40907Starting tor with --DormantOnFirstStartup doesn't set GETINFO dormant to 12024-01-24T19:08:12ZCrazyChaozStarting tor with --DormantOnFirstStartup doesn't set GETINFO dormant to 1### Summary
Starting tor with --DormantOnFirstStartup 1 on a new DataDirectory doesn't set GETINFO dormant to 1
### Steps to reproduce:
1. start tor with ```tor --DormantOnFirstStartup 1 --DataDirectory some-empty-dir```
2. do a ```GE...### Summary
Starting tor with --DormantOnFirstStartup 1 on a new DataDirectory doesn't set GETINFO dormant to 1
### Steps to reproduce:
1. start tor with ```tor --DormantOnFirstStartup 1 --DataDirectory some-empty-dir```
2. do a ```GETINFO dormant```
### What is the current bug behavior?
GETINFO dormant returns 0, as if it weren't in dormant mode
### What is the expected behavior?
GETINFO dormant returns 1, as it is in dormant mode
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
- 0.4.6.10 and 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.
- Pop!_OS 22.04 and Ubuntu 18.04.6
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
- apt and ?Tor: 0.4.9.x-freeze