Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-07-07T00:47:10Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40434Don't set router is_running=false after intentionally closing a directory con...2022-07-07T00:47:10ZoparaDon't set router is_running=false after intentionally closing a directory connectionIn a testing tor network with a few relays, clients, and an onion service, the onion service will call `run_upload_descriptor_event()` periodically to upload its service descriptor. This eventually calls `directory_initiate_request()` wh...In a testing tor network with a few relays, clients, and an onion service, the onion service will call `run_upload_descriptor_event()` periodically to upload its service descriptor. This eventually calls `directory_initiate_request()` which creates a new dir connection for the upload. In the future when `run_upload_descriptor_event()` runs again, it will first call `close_directory_connections()` to mark for close any existing/incomplete descriptor uploads for that service. Later (on the next 1 second libevent timer) the dir connection will be closed and since the upload didn't finish, `connection_dir_client_request_failed()` will set the router's `is_running` field to false.
The problem is that `run_upload_descriptor_event()` can run shortly after a previous run, and in a shadow simulation, this can run only 2 seconds after a previous run. If the descriptor upload has not finished in this 2 seconds, the router will be marked as not running and will not be added to the routerlist when building circuits. Since this dir client request can fail often due to tor's new circuit timeout learning, in small tor networks we quickly run out of nodes in the routerlist, and end up with:
```
Jan 01 00:17:50.000 [info] compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as middle node
Jan 01 00:17:50.000 [info] router_choose_random_node(): We couldn't find any live, stable routers; falling back to list of all routers.
Jan 01 00:17:50.000 [info] compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as middle node
Jan 01 00:17:50.000 [warn] No available nodes when trying to choose node. Failing.
Jan 01 00:17:50.000 [info] pick_needed_intro_points(): Unable to find a suitable node to be an introduction point for service r4aj4kaqf46mala2yykldkvwrrwjagab2qppuqtvgdxwh6spsulwu2qd.
```
I propose to not mark a router as "not running" if tor intentionally closes a directory connection (except maybe for a `TestingDirConnectionMaxStall` timeout).Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40429configure detects wrong openssl version2022-07-07T00:47:10ZpseudonymisaTorconfigure detects wrong openssl version### Summary
configure detects wrong openssl version
### Steps to reproduce:
No matter `--enable-static-openssl` is set or not
1. `./configure`
### What is the current bug behavior?
```
configure:9946: Now, we'll look for OpenSSL >=...### Summary
configure detects wrong openssl version
### Steps to reproduce:
No matter `--enable-static-openssl` is set or not
1. `./configure`
### What is the current bug behavior?
```
configure:9946: Now, we'll look for OpenSSL >= 1.0.1 no
configure:10286: checking for OpenSSL >= 3.0.0 yes
```
2. tor
`Tor 0.4.5.9 running on.......... OpenSSL 1.1.1k`
### What is the expected behavior?
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
`Tor 0.4.5.9`
- Which operating system are you using? For example:
Debian GNU/Linux
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
apt, tarball, Git
### Relevant logs and/or screenshots
```
configure:9946: Now, we'll look for OpenSSL >= 1.0.1
configure:9967: checking for openssl directory
configure:10254: result: (none)
configure:10286: checking for OpenSSL >= 3.0.0
conftest.c:57:2: error: #error "you_have_version_3"
57 | #error "you_have_version_3"
| ^~~~~
configure:10304: $? = 1
| #if !defined(LIBRESSL_VERSION_NUMBER) && OPENSSL_VERSION_NUMBER <= 0x30000000L
| #error "you_have_version_3"
configure:10308: result: yes
configure:10316: checking for OpenSSL < 1.0.1
configure:10334: $? = 0
configure:10335: result: no
configure:10362: $? = 0
configure:10369: checking for significant mismatch between openssl headers and libraries
configure:10411: result: no
```
```
configure: Now, we'll look for OpenSSL >= 1.0.1
checking for openssl directory... /ucrt64/lib
checking whether we need extra options to link openssl... (none)
checking for OpenSSL >= 3.0.0... yes
checking for OpenSSL < 1.0.1... no
checking for significant mismatch between openssl headers and libraries... no
```
### Possible fixesNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40428build flag not working unrecognized options: --disable-module-dircache2022-06-22T15:30:19ZpseudonymisaTorbuild flag not working unrecognized options: --disable-module-dircache### Summary
### Steps to reproduce:
1. Step 1: `./configure --disable-module-dirauth `
2. Output:
```
WARNING: unrecognized options: --disable-module-dircache
Modules
dircache (--disable-module-dircache): ...### Summary
### Steps to reproduce:
1. Step 1: `./configure --disable-module-dirauth `
2. Output:
```
WARNING: unrecognized options: --disable-module-dircache
Modules
dircache (--disable-module-dircache): yes
```
### What is the current bug behavior?
The build flag can't be disabled, as it is unrecognized
### What is the expected behavior?
`--disable-module-dircache` should set the build flag to no as described.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
tor-0.4.5.9
- Which operating system are you using? For example:
Debian GNU/Linux
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
apt & tarball & Git
### Relevant logs and/or screenshots
tor-0.4.5.9/config.log
`configure:29693: WARNING: unrecognized options: --disable-module-dircache`
#33646
### Possible fixes
?https://gitlab.torproject.org/tpo/core/tor/-/issues/40419Android: FAIL src/test/test_address_set.c:80: assert(ret OP_EQ 1): 0 vs 12022-07-07T00:47:10ZeighthaveAndroid: FAIL src/test/test_address_set.c:80: assert(ret OP_EQ 1): 0 vs 1### Summary
I rebased our Android patches on tor-0.4.6.5 and ran the CI. It passed on _android-24/armeabi-v7a_ and failed on _android-22/x86_64_. Both pass on tor-0.4.5.9. This is the failure:
```console
address_set/contains: [forki...### Summary
I rebased our Android patches on tor-0.4.6.5 and ran the CI. It passed on _android-24/armeabi-v7a_ and failed on _android-22/x86_64_. Both pass on tor-0.4.5.9. This is the failure:
```console
address_set/contains: [forking]
FAIL src/test/test_address_set.c:80: assert(ret OP_EQ 1): 0 vs 1
[contains FAILED]
```
https://gitlab.com/eighthave/tor/-/jobs/1367099673
My guess is that this is either an intermittent bug or it is due to the CPU arch.
### Steps to reproduce:
1. fork https://gitlab.com/eighthave/tor
2. trigger a CI pipeline on the tag _tor-android-0.4.6.5_
### Environment
Running on Debian/stretch via the Docker image `registry.gitlab.com/fdroid/ci-images-client`. The emulator is running without KVM support, so it is very slow.
### Possible fixes
If that test is not relevant on Android, I can disable it in our fork.
FYI @n8fr8 @sysrqbTor: 0.4.6.x-post-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40410ratelim.h:55:27: error: initializer element is not constant2022-07-07T00:47:10Zacidsysratelim.h:55:27: error: initializer element is not constant### Summary
### Steps to reproduce:
1. Clone latest master (0.4.7.0-alpha-dev as of 10/06/2021)
2. ./autogen.sh
3. ./configure
4. make
### What is the current bug behavior?
```
CC src/feature/dircache/dircache.o
CC ...### Summary
### Steps to reproduce:
1. Clone latest master (0.4.7.0-alpha-dev as of 10/06/2021)
2. ./autogen.sh
3. ./configure
4. make
### What is the current bug behavior?
```
CC src/feature/dircache/dircache.o
CC src/feature/dircache/dirserv.o
CC src/feature/dirclient/dirclient.o
In file included from ./src/core/or/or.h:50:0,
from src/feature/dirclient/dirclient.c:13:
src/feature/dirclient/dirclient.c: In function ‘dir_client_decompress_response_body’:
./src/lib/log/ratelim.h:55:27: error: initializer element is not constant
#define RATELIM_INIT(r) { (r), 0, 0, 0 }
^
src/feature/dirclient/dirclient.c:1911:38: note: in expansion of macro ‘RATELIM_INIT’
static ratelim_t warning_limit = RATELIM_INIT(LOG_INTERVAL);
^~~~~~~~~~~~
./src/lib/log/ratelim.h:55:27: note: (near initialization for ‘warning_limit.rate’)
#define RATELIM_INIT(r) { (r), 0, 0, 0 }
^
src/feature/dirclient/dirclient.c:1911:38: note: in expansion of macro ‘RATELIM_INIT’
static ratelim_t warning_limit = RATELIM_INIT(LOG_INTERVAL);
^~~~~~~~~~~~
make[1]: *** [Makefile:11154: src/feature/dirclient/dirclient.o] Error 1
make[1]: Leaving directory '/home/georg/new/tor'
make: *** [Makefile:6180: all] Error 2
```
### What is the expected behavior?
Either the program should compile without any errors, or configure should inform about dependency issues.
### Failed Environment
- openSUSE Leap 15.2
- Tor 0.4.7.0-alpha-dev via git clone
- GNU Autoconf 2.69
- GNU Make 4.2.1
- gcc (SUSE Linux) 7.5.0
### Working environment
- openSUSE Tumbleweed
- Tor 0.4.7.0-alpha-dev via git clone
- autoconf (GNU Autoconf) 2.69
- GNU Make 4.3
- gcc (SUSE Linux) 10.3.0
### Possible fixes
No solution or workaround found so far.
### Suggestion
In case the compatibility with older (stable) distributions is not restorable, an exemption should be implemented in configureTor: 0.4.5.x-post-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40396Good bridge + bad bridge = no bootstrap2023-01-10T17:59:43ZanonymGood bridge + bad bridge = no bootstrap### Summary
If I configure `tor` with one known-good bridge and one known-bad bridge (e.g. the host is simply not a bridge) then `tor` refuses to bootstrap.
(By the way, in Tor Browser the UX is pretty bad in this situation, because To...### Summary
If I configure `tor` with one known-good bridge and one known-bad bridge (e.g. the host is simply not a bridge) then `tor` refuses to bootstrap.
(By the way, in Tor Browser the UX is pretty bad in this situation, because Tor Launcher just stays at 70% progress and never reports an error to the user.)
### What is the current bug behavior?
We get stuck with:
> May 17 11:10:35.000 [info] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6540/6540). That's ok. We will try to fetch missing descriptors soon.
### What is the expected behavior?
I expected `tor` to ignore the bad bridge and successfully bootstrap using only the good bridge.
### Environment
This is the case both in Tails, Debian Sid and Tor Browser 10.0.16.
### Possible fixes and discussion
I wonder, if this is not a bug, is this because even when using bridges, `tor` tries to respect `guard-n-primary-guards-to-use`/`NumEntryGuards`? If so there seems to be an exception when only one (know-good) bridge is provided, because then bootstrapping works. Is all this expected/intended? Or am I confused?
Taking a step back, to me it seems harsh on users to enforce something like `NumEntryGuards` for user-configured bridges since it puts a lot of responsibility on them to ensure at least two are working, with no clear way for them check that (basically, they have to read and understand the logs). Otherwise the software used to configure `tor` (e.g. Tor Launcher, or its replacements) has to get better at detecting individual bridge failures and give the user some way to drop bad ones.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40356Leaksanitizer detected memory leak with Tor Tor 0.4.6.1-alpha-dev (git-769d54...2022-07-07T00:47:10ZGeorg KoppenLeaksanitizer detected memory leak with Tor Tor 0.4.6.1-alpha-dev (git-769d54c5d7933ccb)I hit a memory leak with the latest `tor` code from `master` when using it in Tor Browser. No special usage, no bridges. Just normal browsing in a bunch of tabs and closing the browser after it had been running a full day:
```
Direct lea...I hit a memory leak with the latest `tor` code from `master` when using it in Tor Browser. No special usage, no bridges. Just normal browsing in a bunch of tabs and closing the browser after it had been running a full day:
```
Direct leak of 392 byte(s) in 7 object(s) allocated from:
#0 0x7f77ac8bae8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x56288c6b1778 in tor_malloc_ ../src/lib/malloc/malloc.c:45
#2 0x56288c6b1810 in tor_malloc_zero_ ../src/lib/malloc/malloc.c:71
#3 0x56288c89354d in cache_client_desc_new ../src/feature/hs/hs_cache.c:460
#4 0x56288c89354d in hs_cache_store_as_client ../src/feature/hs/hs_cache.c:873
#5 0x56288c8a2dd5 in client_dir_fetch_200 ../src/feature/hs/hs_client.c:1463
#6 0x56288c8a2dd5 in hs_client_dir_fetch_done ../src/feature/hs/hs_client.c:2379
#7 0x56288c834fa8 in handle_response_fetch_hsdesc_v3 ../src/feature/dirclient/dirclient.c:2721
#8 0x56288c834fa8 in connection_dir_client_reached_eof ../src/feature/dirclient/dirclient.c:2139
#9 0x56288c834fa8 in connection_dir_reached_eof ../src/feature/dirclient/dirclient.c:2787
#10 0x56288c7d1ff1 in connection_reached_eof ../src/core/mainloop/connection.c:5243
#11 0x56288c7d1ff1 in connection_handle_read_impl ../src/core/mainloop/connection.c:4014
#12 0x56288c58c240 in conn_read_callback ../src/core/mainloop/mainloop.c:891
#13 0x7f77ac47c22e (TorBrowser/Tor/libevent-2.1.so.7+0x2322e)
```
I am attaching the whole LeakSanitizer output, too.Tor: 0.4.6.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40341Windows 32-bit build broken with introduction of `overload_happened_recently(...2022-07-07T00:47:10ZAlexander Færøyahf@torproject.orgWindows 32-bit build broken with introduction of `overload_happened_recently()` in rephist.cCommit 0a5ecb334298187a64f58382231245111130aa76 introduced a new function named `overload_happened_recently()` which does a comparison between signed and unsigned data on 32-bit Windows.
The error is:
```
src/feature/stats/rephist.c: I...Commit 0a5ecb334298187a64f58382231245111130aa76 introduced a new function named `overload_happened_recently()` which does a comparison between signed and unsigned data on 32-bit Windows.
The error is:
```
src/feature/stats/rephist.c: In function ‘overload_happened_recently’:
src/feature/stats/rephist.c:215:21: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (overload_time > approx_time() - 3600 * n_hours) {
```
See: https://travis-ci.org/github/ahf/tor-win32/jobs/763284597#L8775-L8777Tor: 0.4.6.x-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/40337Relays don't actually notice bandwidth changes for a day2022-07-07T00:47:10ZRoger DingledineRelays don't actually notice bandwidth changes for a daySummary:
The current Tor has a bug where it assesses what "bandwidth observed" to put in its descriptor using only the bandwidth it saw itself do *yesterday* or earlier. This bug is especially sad for testing tor networks like chutney b...Summary:
The current Tor has a bug where it assesses what "bandwidth observed" to put in its descriptor using only the bandwidth it saw itself do *yesterday* or earlier. This bug is especially sad for testing tor networks like chutney because 24 hours ago is a long time for a chutney network; but it is also sad for relays bootstrapping in general because they don't behave in the way we thought they did.
Background:
Relays self-assess their own observed bandwidth by looking at the highest 10-second burst they've seen themselves do in either direction and picking the smaller of these two bursts. Specifically, they keep a set of previous largest bursts for past epochs, and a running count of the largest burst so far in the current epoch. When an epoch ends, they push all the epoch counts back one and store the current largest burst as the most recent epoch. When they want to know what number to put in the descriptor, they look for the highest burst among the past epochs, and they don't look at the current running largest.
At the dawn of time (Tor 0.0.8pre1 through Tor 0.2.6.3-alpha), the epochs lasted 15 minutes, so you'd need to wait up to 15 minutes before the current running total got stored and then counted for a new bandwidth estimate.
But then in Tor 0.2.6.3-alpha we moved that "15 minutes" up to "4 hours" (tor#13988, git commit 6830667d58), and then in Tor 0.3.2.6-alpha we moved from 4 hours to 24 hours (tor#23856, git commit 8be50ca3ea9). That's when things went bad for the relay capacity estimation: we continued only asking ourselves about past epochs, even though the past epochs got farther and farther in the past.
This feature is now at odds with, for example, the feature in check_descriptor_bandwidth_changed() that decides that big bandwidth shifts are only a good reason to publish a new descriptor if our uptime is less than 24 hours.Tor: 0.4.6.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40330Bug - Heartbeat log message does not consider the value of the "HeartbeatPeri...2022-07-07T00:47:10ZcypherpunksBug - Heartbeat log message does not consider the value of the "HeartbeatPeriod" value.The problem is in the file `/feature/stats/geoip_stats.c`, at the fonction `format_client_stats_heartbeat()`. The variable `n_hours` is hardcoded to 6 hours, which is the default value. Here is the changes I made to the fonction. I take ...The problem is in the file `/feature/stats/geoip_stats.c`, at the fonction `format_client_stats_heartbeat()`. The variable `n_hours` is hardcoded to 6 hours, which is the default value. Here is the changes I made to the fonction. I take the opportunity to do a little bit of refactoring. I did not know how to compile the project and test it, but I'm sure you will understand what I'm trying to do.
To fix this issue, `n_hours`, now renamed `n_heartbeat_period`, need to take the value of the `option->HeartbeatPeriod`, which is in seconds.
~~~
[- Line 1207 : const int n_hours = 6; -]
[+ Line 1207 : const int n_heartbeat_period = option->HeartbeatPeriod; +]
[- Line 1211 : unsigned cutoff = (unsigned)( (now-n_hours*3600)/60 ); -]
[+ Line 1211 : unsigned cutoff = (unsigned)( (now-n_heartbeat_period)/60 ); +]
[- Line 1228 : nhours, -]
[+ Line 1228 : n_heartbeat_period +]
~~~
The variable `out` could also be renamed `msg`.
~~~
[- Line 1208 : char *out = NULL; -]
[+ Line 1208 : char *msg = NULL; +]
[- Line 1226 : tor_asprintf(&out, "Heartbeat: " -]
[+ Line 1226 : tor_asprintf(&msg, "Heartbeat: " +]
[- Line 1231 : return out; -]
[+ Line 1231 : return msg; +]
~~~
A `clientmap_entry_t` is a `client`, so why not call it that way to make it more clear instead of `ent`.
~~~
[- Line 1210 : clientmap_entry_t **ent; -]
[+ Line 1210 : clientmap_entry_t **client; +]
[- Line 1217 : HT_FOREACH(ent, clientmap, &client_history) { -]
[+ Line 1217 : HT_FOREACH(client, clientmap, &client_history) { +]
[- Line 1219 : if ((*ent)->action != GEOIP_CLIENT_CONNECT) -]
[+ Line 1219 : if ((*client)->action != GEOIP_CLIENT_CONNECT) +]
[- Line 1221 : if ((*ent)->last_seen_in_minutes < cutoff) -]
[+ Line 1221 : if ((*client)->last_seen_in_minutes < cutoff) +]
~~~
Prettier `msg` :simple_smile:
~~~
[- Line 1226 : tor_asprintf(&out, "Heartbeat: " -]
[- Line 1227 : "In the last %d hours, I have seen %d unique clients.", -]
[- Line 1228 : n_hours, -]
[- Line 1229 : n_clients); -]
[+ Line 1226 : tor_asprintf(&msg, "Heartbeat: In the last %d hour%s, I have seen %u unique client%s.", +]
[+ Line 1227 : n_heartbeat_period*60*60, +]
[+ Line 1228 : n_heartbeat_period >= 60*60*2 ? "s" : "", +]
[+ Line 1229 : n_clients, +]
[+ Line 1230 : n_clients > 1 ? "s" : ""); +]
~~~
Message to the moderator about my `GitLab Flavored Markdown` skills :
My last issue is **horrible** and this one will certainly be, because I can't validate the formating before submitting it! I'm so sorry.Tor: 0.4.6.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40317Cannot SAVECONF when the seccomp sandbox is enabled2022-07-07T00:47:10ZanonymCannot SAVECONF when the seccomp sandbox is enabled### Summary
Issuing a `SAVECONF` to `tor` when the seccomp sandbox is enabled fails.
### Steps to reproduce:
1. Start `tor` with `Sandbox 1` set and controller access
2. Send `SAVECONF` via the controller
### What is the current bug ...### Summary
Issuing a `SAVECONF` to `tor` when the seccomp sandbox is enabled fails.
### Steps to reproduce:
1. Start `tor` with `Sandbox 1` set and controller access
2. Send `SAVECONF` via the controller
### What is the current bug behavior?
Sending a `SAVECONF` currently results in this answer:
```
250 OK
551 Unable to write configuration to disk.
250 closing connection
```
and `tor` logs:
```
Mar 05 11:31:28.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.orig.1 (on Tor 0.4.5.6 )
Mar 05 11:31:28.000 [notice] Renaming old configuration file to "/etc/tor/torrc.orig.1"
Mar 05 11:31:28.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.orig.1 (on Tor 0.4.5.6 )
Mar 05 11:31:28.000 [warn] Couldn't rename configuration file "/etc/tor/torrc" to "/etc/tor/torrc.orig.1": Operation not permitted
```
and unsurprisingly the current `tor` configuration was not saved to `torrc`.
### What is the expected behavior?
`SAVECONF` should work even when the seccomp sandbox is enabled.
### Environment
I tried with both `tor` 0.4.4.6 and 0.4.5.6 on an Debian Buster, using your `.deb`:s.
### Relevant logs and/or screenshots
Except the log I posted above, sometimes I saw this instead but I don't know why it's different:
```
Mar 05 12:06:00.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.tmp (on Tor 0.4.4.6 )
Mar 05 12:06:00.000 [warn] Couldn't open "/etc/tor/torrc.tmp" (/etc/tor/torrc) for writing: Operation not permitted
```Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40285Bug: 2-hop circuit with purpose 5 has no guard state2022-07-07T00:47:09ZRoger DingledineBug: 2-hop circuit with purpose 5 has no guard stateWhen I issue an "extendcircuit 0 A,B" command with my controller, and the circuit gets built, my Tor logs a line like:
```
Feb 09 20:36:44.400 [warn] circuit_build_no_more_hops(): Bug: 2-hop circuit 0x5558a75e2190 with purpose 5 has no g...When I issue an "extendcircuit 0 A,B" command with my controller, and the circuit gets built, my Tor logs a line like:
```
Feb 09 20:36:44.400 [warn] circuit_build_no_more_hops(): Bug: 2-hop circuit 0x5558a75e2190 with purpose 5 has no guard state (on Tor 0.4.5.5-rc-dev f420eacf1858220f)
```
My extendprobe tester (https://gitlab.torproject.org/tpo/network-health/team/-/issues/16) makes many such circuits, and ends up with many such Bug lines.
See #24966 for a past version of this bug that got closed.
This issue isn't a big deal, except for the log spam, and maybe we still (hopefully we still?) have an invariant goal where Tor isn't supposed to issue any "Bug" lines during ordinary expected behavior.Tor: 0.4.6.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40237v3 onion services require a "live" consensus to publish or fetch2022-07-07T00:48:32ZRoger Dingledinev3 onion services require a "live" consensus to publish or fetchIf the Tor v3 onion client, or Tor v3 onion service, do not have a "live" consensus (i.e. one where "valid-until" hasn't elapsed), then they will choose not to even attempt to fetch or publish v3 onion descriptors:
```
Jan 10 11:32:24.36...If the Tor v3 onion client, or Tor v3 onion service, do not have a "live" consensus (i.e. one where "valid-until" hasn't elapsed), then they will choose not to even attempt to fetch or publish v3 onion descriptors:
```
Jan 10 11:32:24.364 [warn] No live consensus so we can't get the responsible hidden service directories.
```
This bug got exposed today because the network went several rounds without a consensus due to the ongoing issues of #33018 and #33072, and thus Tor clients and Tor onion services ended up with a consensus that still worked (it was made within the past 24 hours), but was no longer considered "live".
So normal Tor circuits (using exit relays) still worked, and v2 onion services still worked, but v3 onion services stopped working for that time period -- services wouldn't publish descriptors, and clients wouldn't fetch them.
The fix imo is that we need to make v3 onion services work under the same time assumptions as the other parts of Tor -- if you have a usable consensus, then use it.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40236configure summary misleadingly indicates library support based on enable, not...2022-07-07T00:48:32ZAlex Xuconfigure summary misleadingly indicates library support based on enable, not havewhen --enable-zstd, --enable-lzma, etc are set to auto, they are listed in the configure summary as "no" regardless of whether they were detected and used.when --enable-zstd, --enable-lzma, etc are set to auto, they are listed in the configure summary as "no" regardless of whether they were detected and used.Tor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40234Non-fatal assertion !(smartlist_len(outdated_dirserver_list) > TOO_MANY_OUTDA...2022-07-07T00:48:32ZNick MathewsonNon-fatal assertion !(smartlist_len(outdated_dirserver_list) > TOO_MANY_OUTDATED_DIRSERVERS)A user sent me this email saying that they'd gotten this bug on their relay.
```
tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:133:
microdesc_note_outdated_dirserver: Non-fatal assertion
!(smartlist_len(outdated_dirserv...A user sent me this email saying that they'd gotten this bug on their relay.
```
tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:133:
microdesc_note_outdated_dirserver: Non-fatal assertion
!(smartlist_len(outdated_dirserver_list) > TOO_MANY_OUTDATED_DIRSERVERS)
failed. (on Tor 0.4.4.6 )
Bug: Tor 0.4.4.6: Non-fatal assertion
!(smartlist_len(outdated_dirserver_list) > TOO_MANY_OUTDATED_DIRSERVERS)
failed in microdesc_note_outdated_dirserver at
../src/feature/nodelist/microdesc.c:133. Stack trace: (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(log_backtrace_impl+0x56) [0x55bdb35379d6] (on Tor
0.4.4.6 )
Bug: /usr/bin/tor(tor_bug_occurred_+0x16c) [0x55bdb3532bdc] (on Tor
0.4.4.6 )
Bug: /usr/bin/tor(microdesc_note_outdated_dirserver+0x147)
[0x55bdb34563c7] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(+0x1085fb) [0x55bdb341d5fb] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(+0x10b588) [0x55bdb3420588] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(connection_dir_reached_eof+0x29) [0x55bdb3422e09]
(on Tor 0.4.4.6 )
Bug: /usr/bin/tor(connection_handle_read+0x8bc) [0x55bdb33862dc]
(on Tor 0.4.4.6 )
Bug: /usr/bin/tor(+0x76729) [0x55bdb338b729] (on Tor 0.4.4.6 )
Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba)
[0x7f0bd5d2e9ba] (on Tor 0.4.4.6 )
Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)
[0x7f0bd5d2f537] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(do_main_loop+0xff) [0x55bdb338c9af] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(tor_run_main+0x885) [0x55bdb33793a5] (on Tor
0.4.4.6 )
Bug: /usr/bin/tor(tor_main+0x3a) [0x55bdb33772ca] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(main+0x19) [0x55bdb3376e89] (on Tor 0.4.4.6 )
Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)
[0x7f0bd561009b] (on Tor 0.4.4.6 )
Bug: /usr/bin/tor(_start+0x2a) [0x55bdb3376eda] (on Tor 0.4.4.6 )
```Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40233Assertion when starting an IPv4-only bridge on 0.4.5.2-alpha2022-07-07T00:48:32ZNeel Chauhanneel@neelc.orgAssertion when starting an IPv4-only bridge on 0.4.5.2-alphaWhen I set up a bridge on FreeBSD, I got this issue.
Jan 01 21:10:44.000 [notice] Bootstrapped 0% (starting): Starting
Jan 01 21:10:44.000 [notice] Starting with guard context "default"
Jan 01 21:10:44.000 [notice] Registere...When I set up a bridge on FreeBSD, I got this issue.
Jan 01 21:10:44.000 [notice] Bootstrapped 0% (starting): Starting
Jan 01 21:10:44.000 [notice] Starting with guard context "default"
Jan 01 21:10:44.000 [notice] Registered server transport 'obfs4' at '[::]:80'
Jan 01 21:10:45.000 [warn] tor_bug_occurred_: Bug: src/feature/relay/relay_find_addr.c:201: relay_addr_learn_from_dirauth: Non-fatal assertion !(!node) failed. (on Tor 0.4.5.2-alpha )
Jan 01 21:10:
Jan 01 21:10:45.000 [warn] Bug: 0x11a2ad2 <router_build_fresh_descriptor+0x2a2> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x11a1f3f <router_rebuild_descriptor+0x6f> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x11a1d49 <consider_publishable_server+0x39> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1225714 <reschedule_descriptor_update_check+0x274> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x122a77a <periodic_event_connect+0x10a> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x8013fe0ed <event_base_assert_ok_nolock_+0xa5d> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x8013fa09c <event_base_loop+0x53c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x116c861 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1155cbc <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1154651 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
Jan 01 21:10:45.000 [warn] Bug: 0x1154309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.5.2-alpha )
This happened on FreeBSD 12.2 on a bridge on Microsoft Azure. Tor was installed via `pkg` and I do not have a local-link IPv6 address.Tor: 0.4.5.x-post-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40232"Closing no-longer-configured OR listener" does not put brackets around IPv6 ...2021-07-09T17:22:52ZNeel Chauhanneel@neelc.org"Closing no-longer-configured OR listener" does not put brackets around IPv6 addressesWhen I was setting `IPv4Only` on a new Tor relay with broken IPv6, and did `killall -HUP tor`, I got this:
Dec 23 20:08:02.000 [notice] Closing no-longer-configured OR listener on :::143
(I believe) the `:::143` should be `[::]:143`.When I was setting `IPv4Only` on a new Tor relay with broken IPv6, and did `killall -HUP tor`, I got this:
Dec 23 20:08:02.000 [notice] Closing no-longer-configured OR listener on :::143
(I believe) the `:::143` should be `[::]:143`.https://gitlab.torproject.org/tpo/core/tor/-/issues/40224Find a working alternative to using MaxMind's GeoLite2 databases2024-01-25T11:54:26ZKarsten LoesingFind a working alternative to using MaxMind's GeoLite2 databasesMaxMind has recently changed access and use of their GeoLite2 databases: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/
This affects Onionoo and tor. I started a [thread on tor-dev@](h...MaxMind has recently changed access and use of their GeoLite2 databases: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/
This affects Onionoo and tor. I started a [thread on tor-dev@](https://lists.torproject.org/pipermail/tor-dev/2020-January/014117.html) about this topic last week with some more details.
Let's use this ticket to brainstorm and discuss working alternatives to the way we used their databases in the past.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40210Tor generates invalid address for hiddenservice when running on armv5tel arch...2021-07-09T17:22:00ZAlexander Færøyahf@torproject.orgTor generates invalid address for hiddenservice when running on armv5tel architectures (from Debian)@weasel posted the following ticket today on IRC from Debian issue tracker:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977
Maybe this is something we should look into? Looks like it's going back all the way to 0.3.5.@weasel posted the following ticket today on IRC from Debian issue tracker:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977
Maybe this is something we should look into? Looks like it's going back all the way to 0.3.5.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/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 Mathewson