Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:48:19Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33226Prop 311: 5. Declare Support for Subprotocol Version "Relay=3"2020-06-27T13:48:19ZteorProp 311: 5. Declare Support for Subprotocol Version "Relay=3"This ticket depends on relay IPv6 extends in legacy/trac#33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this propo...This ticket depends on relay IPv6 extends in legacy/trac#33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See proposal 311, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n601Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40384move doxygen docs to GitLab CI or deprecate2021-08-30T17:59:27Zanarcatmove doxygen docs to GitLab CI or deprecatein tpo/tpa/team#40225, i was asked to "remove or disable Tor jenkins builders". while doing that, I noticed that doxgen docs are not currently build in a known location in GitLab CI:
https://src-ref.docs.torproject.org/tor/index.html
s...in tpo/tpa/team#40225, i was asked to "remove or disable Tor jenkins builders". while doing that, I noticed that doxgen docs are not currently build in a known location in GitLab CI:
https://src-ref.docs.torproject.org/tor/index.html
so retiring those would mean leaving that stale website in place for the foreseeable future.
could you move that to GitLab CI and GitLab pages? the following should get you started:
https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab/#publishing-gitlab-pages
if not, do let me know what's your blocker. i *believe* the resulting URL for core tor would be:
https://tpo.pages.torproject.net/core/tor/
once that is done we can retire the jenkins job, and then provide a redirect to the gitlab pages.
makes sense?Retire JenkinsAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40430Modify default torrc text for PublishServerDescriptor2021-07-08T18:19:04ZCecylia BocovichModify default torrc text for PublishServerDescriptorIn the default torrc file, we see:
```
## By default, Tor will advertise your bridge to users through various
## mechanisms like https://bridges.torproject.org/. If you want to run
## a private bridge, for example because you'll give out...In the default torrc file, we see:
```
## By default, Tor will advertise your bridge to users through various
## mechanisms like https://bridges.torproject.org/. If you want to run
## a private bridge, for example because you'll give out your bridge
## address manually to your friends, uncomment this line:
#PublishServerDescriptor 0
```
However, we've noticed that some default Tor and Orbot bridges are not publishing their descriptors and therefore we aren't getting any metrics from them. This is exactly the use-case that `BridgeDistribution none` was meant to handle. In general, we recommend that people running private (or default) bridges that aren't meant for BridgeDB to configure their torrc file to have:
```
PublishServerDescriptor 1
BridgeDistribution none
```
See also the text in the torrc manpage for `PublishServerDescriptor`:
```
PublishServerDescriptor 0|1|v3|bridge,...
This option specifies which descriptors Tor will publish when acting as a relay. You
can choose multiple arguments, separated by commas.
If this option is set to 0, Tor will not publish its descriptors to any directories.
(This is useful if you’re testing out your server, or if you’re using a Tor controller
that handles directory publishing for you.) Otherwise, Tor will publish its descriptors
of all type(s) specified. The default is "1", which means "if running as a relay or
bridge, publish descriptors to the appropriate authorities". Other possibilities are
"v3", meaning "publish as if you’re a relay", and "bridge", meaning "publish as if
you’re a bridge".
```
I think we should change the default torrc text to match the manpage and say something to the effect of "if you want to, you can avoid publishing your descriptors, but we recommend that you do and that you set `BridgeDistribution none` if you don't want your bridge distributed over BridgeDB. That way we can collect metrics."Tor: 0.4.7.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40352Nonauthoritative directory does not accept posted server descriptors2021-10-19T12:31:25ZTommaso GragnatoNonauthoritative directory does not accept posted server descriptors```[WARN] http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver 185.107.47.215:9001. Malformed rendezvous descriptor? [6 duplicates hidden]```
I suspect this is because [185.107...```[WARN] http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver 185.107.47.215:9001. Malformed rendezvous descriptor? [6 duplicates hidden]```
I suspect this is because [185.107.47.215](https://metrics.torproject.org/rs.html#details/45E9240AD4ECE01793A1977C1260503B2C2C861F) is running 0.4.6 alpha and does not understand descriptors for v2 onions. Hence the 400.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40266#note_2724898
Should this be handled gracefully? What's the phase out plan?Tor: 0.4.7.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40294Detect the need for and enable '__USE_MINGW_ANSI_STDIO=0' in configure2021-10-19T12:29:39ZAlexander Færøyahf@torproject.orgDetect the need for and enable '__USE_MINGW_ANSI_STDIO=0' in configureCurrently when building Tor on Windows with a modern MinGW-based toolchain, it is necessary to have `CFLAGS='-D__USE_MINGW_ANSI_STDIO=0'"` defined. We should detect this in `configure` and enable it if needed automatically.
In commit d9...Currently when building Tor on Windows with a modern MinGW-based toolchain, it is necessary to have `CFLAGS='-D__USE_MINGW_ANSI_STDIO=0'"` defined. We should detect this in `configure` and enable it if needed automatically.
In commit d9cc2b2928eab045f89d0abf95a9e5c75e290ff8, this was enabled for our AppVeyor builds by explicitly setting the definition in the `CFLAGS` variable.
An example of the error that happens when this is not set:
```
In file included from ./src/lib/crypt_ops/crypto_rsa.h:21,
from ./src/core/or/or.h:31,
from src/core/mainloop/connection.c:58:
src/core/mainloop/connection.c: In function ‘connection_free_minimal’:
src/core/mainloop/connection.c:875:16: error: unknown conversion type character ‘l’ in format [-Werror=format=]
875 | "Freeing orconn at %p, saw channel %p with ID "
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c:875:16: error: too many arguments for format [-Werror=format-extra-args]
875 | "Freeing orconn at %p, saw channel %p with ID "
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c: In function ‘connection_close_immediate’:
src/core/mainloop/connection.c:1056:21: error: unknown conversion type character ‘l’ in format [-Werror=format=]
1056 | log_info(LD_NET,"fd %d, type %s, state %s, %"TOR_PRIuSZ" bytes on outbuf.",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c:1056:21: error: too many arguments for format [-Werror=format-extra-args]
1056 | log_info(LD_NET,"fd %d, type %s, state %s, %"TOR_PRIuSZ" bytes on outbuf.",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c: In function ‘connection_connect_sockaddr’:
src/core/mainloop/connection.c:2242:10: error: unknown conversion type character ‘l’ in format [-Werror=format=]
2242 | "Connection to socket %s (sock "TOR_SOCKET_T_FORMAT").",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:284:43: note: in definition of macro ‘log_fn’
284 | log_fn_(severity, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c:2242:10: error: too many arguments for format [-Werror=format-extra-args]
2242 | "Connection to socket %s (sock "TOR_SOCKET_T_FORMAT").",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:284:43: note: in definition of macro ‘log_fn’
284 | log_fn_(severity, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c: In function ‘connection_dump_buffer_mem_stats’:
src/core/mainloop/connection.c:5552:6: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5552 | "In buffers for %d connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5552:6: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5552 | "In buffers for %d connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5552:6: error: too many arguments for format [-Werror=format-extra-args]
5552 | "In buffers for %d connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/core/mainloop/connection.c:5559:9: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5559 | " For %d %s connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5559:9: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5559 | " For %d %s connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5559:9: error: too many arguments for format [-Werror=format-extra-args]
5559 | " For %d %s connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:12417: src/core/mainloop/connection.o] Error 1
make[2]: Leaving directory '/home/ahf/src/github.com/ahf/tor-win32/src/tor'
make[1]: *** [Makefile:7346: all] Error 2
make[1]: Leaving directory '/home/ahf/src/github.com/ahf/tor-win32/src/tor'
make: *** [Makefile:81: tor] Error 2
```Tor: 0.4.7.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40520module thinko in src/lib/crypt_ops/crypto_rand.c2022-07-07T00:47:11Ztoralfmodule thinko in src/lib/crypt_ops/crypto_rand.c### Summary
I do wonder if
- "modulo 5" should be "modulo 8"
- the bits -> bytes calculation have to made afterwards
- the goal is to calculate the amount of bytes needed for N base32 characters then even the "+7" is wrong
```patch
ind...### Summary
I do wonder if
- "modulo 5" should be "modulo 8"
- the bits -> bytes calculation have to made afterwards
- the goal is to calculate the amount of bytes needed for N base32 characters then even the "+7" is wrong
```patch
index 5bf3a65b3b..90a755537c 100644
--- a/src/lib/crypt_ops/crypto_rand.c
+++ b/src/lib/crypt_ops/crypto_rand.c
@@ -568,9 +568,10 @@ crypto_random_hostname(int min_rand_len, int max_rand_len, const char *prefix,
prefixlen = strlen(prefix);
resultlen = prefixlen + strlen(suffix) + randlen + 16;
- rand_bytes_len = ((randlen*5)+7)/8;
- if (rand_bytes_len % 5)
- rand_bytes_len += 5 - (rand_bytes_len%5);
+ rand_bytes_len = randlen*5;
+ if (rand_bytes_len % 8)
+ rand_bytes_len += 8 - (rand_bytes_len%8);
+ rand_bytes_len /= 8;
rand_bytes = tor_malloc(rand_bytes_len);
crypto_rand(rand_bytes, rand_bytes_len);
```
Or?Tor: 0.4.7.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40342Tor 0.4.5.7 minor log spam; Unable to find IPv6 address for ORPort2021-03-23T18:53:26ZerTor 0.4.5.7 minor log spam; Unable to find IPv6 address for ORPortThats after 6 hours uptime. Initial remark in logs would be ok. Repeating it over and over again after that, this kinda isnt. So there is no ipv6 address configured. Is that illegal? Can you still function? Take a hint, will you? Just m...Thats after 6 hours uptime. Initial remark in logs would be ok. Repeating it over and over again after that, this kinda isnt. So there is no ipv6 address configured. Is that illegal? Can you still function? Take a hint, will you? Just my 2 cents.
```
Mar 17 15:19:36.825 [notice] Tor 0.4.5.7 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1i, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
...
Mar 17 15:20:01.000 [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address.
...
Mar 17 16:20:02.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [62 similar message(s) suppressed in last 3660 seconds]
Mar 17 17:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
Mar 17 18:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3600 seconds]
Mar 17 19:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
Mar 17 20:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
Mar 17 21:20:03.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
```Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/40297Core Tor 0.4.5.6 claims "OpenSSL has been built without thread support" on st...2021-04-13T21:06:21ZpkreuztCore Tor 0.4.5.6 claims "OpenSSL has been built without thread support" on static Mingw buildBuilding on Linux for static win32 and win64. This didn't happen on previous versions, which built correctly with same OpenSSL. Also, this error arises on make step, configure doesn't report any problem:
```
src/lib/crypt_ops/crypto_ope...Building on Linux for static win32 and win64. This didn't happen on previous versions, which built correctly with same OpenSSL. Also, this error arises on make step, configure doesn't report any problem:
```
src/lib/crypt_ops/crypto_openssl_mgt.c:135:2: error: #error "OpenSSL has been built without thread support. Tor requires an OpenSSL library with thread support enabled."
[...]
make[1]:*** [Makefile:16657: src/lib/crypt_ops/libtor_crypt_ops_a-crypto_openssl_mgt.o] Error 1
```Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/402860.4.5 spends 10 minutes at 100% cpu when loading old cached-descriptors* files2021-03-19T17:20:54ZRoger Dingledine0.4.5 spends 10 minutes at 100% cpu when loading old cached-descriptors* filesI started up an old relay that had cached-descriptors* files from a couple years ago.
It maxed out its cpu and sat there for around 10 minutes on a fast cpu, doing whatever it was doing. It ignored kill attempts other than kill -9. Even...I started up an old relay that had cached-descriptors* files from a couple years ago.
It maxed out its cpu and sat there for around 10 minutes on a fast cpu, doing whatever it was doing. It ignored kill attempts other than kill -9. Eventually it finished and things were fine after that.
I tested and both Tor clients and relays encounter the issue. Tor 0.4.4 does not encounter it. Maybe it is related to the tor#40281 / tor#40221 changes?
It's not the end of the world, since it only needs to happen once per upgrade, and maybe if you have recent enough files it doesn't happen to you. But I would feel pretty sorry for people who don't have great CPUs and who get bit by this one.
I'll put the cached-* files up somewhere once I have a ticket number.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40185relay with 0.4.5.1-alpha-dev (git-dd119b277b66c1a7) ignores -INT and -USR12021-10-22T14:17:38Ztoralfrelay with 0.4.5.1-alpha-dev (git-dd119b277b66c1a7) ignores -INT and -USR1It happened here 2x in a row that a relay here could only be terminated (-HUP worked all the time for what it is worth).
OS is a hardened Linux.
FWIW there are 2 relays running at the same hardware under a hardened Gentoo Linux.
The one...It happened here 2x in a row that a relay here could only be terminated (-HUP worked all the time for what it is worth).
OS is a hardened Linux.
FWIW there are 2 relays running at the same hardware under a hardened Gentoo Linux.
The one which is listing at default ports (80 and 443) behaves fine, the other (9001 and 9030 and being a FallbackDir too) however is affected by this issue.
Update: It is independent from being a FallbackDir or not, with bc6c37b202e907ed now the other relay refused to restart - and today -TERM was ignored too at 1 relay.
Nowadays a _kill -HUP_ is ignored after an uptime of only few hours.
I use this cronjob for now to keep both relays aware of signals
```
@hourly (/sbin/rc-service tor reload; /sbin/rc-service tor2 reload) 1>/dev/null
```Tor: 0.4.5.x-post-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40168Circuit Build Timeout should ignore abandon circuits, lower min timeout2022-02-28T18:16:02ZMike PerryCircuit Build Timeout should ignore abandon circuits, lower min timeoutWhile working on https://gitlab.torproject.org/tpo/core/tor/-/issues/40157, @asn and I discovered that the Circuit Build Timeout learned by CBT was too high. It is counting failed circuits and circuits that did not complete as if they we...While working on https://gitlab.torproject.org/tpo/core/tor/-/issues/40157, @asn and I discovered that the Circuit Build Timeout learned by CBT was too high. It is counting failed circuits and circuits that did not complete as if they were the longest build-time ("right-censored" in the Pareto estimator). This caused the resulting Pareto curve to be a poor fit. These circuits weren't actually that slow; their relays were just down or unresponsive. We should not count these circuits in our build time stats. Doing so in onionperf testing makes the Pareto curve fit much tighter.
Additionally, there is a #define CBT_DEFAULT_TIMEOUT_MIN_VALUE that makes the minimum timeout value 1.5 seconds. This is way too high -- timeouts on the network range from 80ms to 500ms now. This minimum should be like 25 or 50ms now.
This should be backported to stable clients for a couple reasons -- we want to eventually tune the network-wide circuit build timeout quantile for Sponsor61 experiments, but we can't do that until all clients compute the same circuit build timeout. Additionally, it is abysmal UX to wait for 1.5 seconds on circuits that will never ever build.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40782Post-Conflux merge: "All routers are down or won't exit -- choosing a doomed ...2023-05-22T14:22:52ZAlexander Færøyahf@torproject.orgPost-Conflux merge: "All routers are down or won't exit -- choosing a doomed exit at random." log messages@toralf reported the following on #tor-dev IRC the other day:
```
150423 16:53:56 toralf: Th elatest git spams the logs with "All routers are down or won't exit -- choosing a doomed
exit at random...@toralf reported the following on #tor-dev IRC the other day:
```
150423 16:53:56 toralf: Th elatest git spams the logs with "All routers are down or won't exit -- choosing a doomed
exit at random." and "Failed to choose an exit server"
150423 16:56:39 + ahf: toralf: expect git main to be a bit wonky right now since we just landed a pretty huge feature
that is going to need a bit of stabilization
150423 16:56:41 + ahf: mikeperry: ^^
150423 16:57:09 toralf: ahf: thx
150423 17:18:43 + armadev: toralf: does it recover? or does it just do that and be useless as a client?
150423 17:22:08 toralf: I run -git here for 3 servers which do act fine otherwise - from the Grafana logs there is no
significant drop down in throughput nor used sockets, the number of inbound from non-relays
migth however a bit lower than before
150423 17:22:12 toralf: aem
150423 17:22:15 toralf: armadev: ^^
150423 17:27:36 toralf: and at my desktop where I do use Tor as a client only it just sapms the log ful, but it
connects fine to one of my bridges
```
All timestamps are UTC.Tor: 0.4.8.x-freezeMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40781Tune algorithms for conflux2023-05-25T18:08:32ZMike PerryTune algorithms for confluxI need to run a bunch of shadow sims to tune the conflux algorithms for latency, throughput, and mem usage, and then update the spec for the new algs.
As part of this, we also need to improve the throughput for simulated Hong Kong endpo...I need to run a bunch of shadow sims to tune the conflux algorithms for latency, throughput, and mem usage, and then update the spec for the new algs.
As part of this, we also need to improve the throughput for simulated Hong Kong endpoints. For some reason, they did not improve as much as Germany did. I suspect the problem is that only switching once per cwnd may be handicapping this throughput for higher latency links. We probably need to allow it to switch more often.
When this is done, we also need a changelog entry: https://gitlab.torproject.org/tpo/core/tor/-/issues/40780Tor: 0.4.8.x-freezeMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40748Change the default of relays per IP address to 42023-05-31T13:11:24ZGeorg KoppenChange the default of relays per IP address to 4Over in #40744 we started allowing 4 relays per IP address via the `AuthDirMaxServersPerAddr` option. I think we should raise the current default, which is 2, accordingly and then update all the specs affected. We might even need a new p...Over in #40744 we started allowing 4 relays per IP address via the `AuthDirMaxServersPerAddr` option. I think we should raise the current default, which is 2, accordingly and then update all the specs affected. We might even need a new proposal for that (including following the whole proposal process)?Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40704relay: Onionskin wait cutoff and MaxOnionQueueDelay in queue should be conse...2022-11-12T09:00:36ZDavid Gouletdgoulet@torproject.orgrelay: Onionskin wait cutoff and MaxOnionQueueDelay in queue should be consensus parametersOur onion queue code, using the CPU thread pool, has this value hardcoded:
```
/** 5 seconds on the onion queue til we just send back a destroy */
#define ONIONQUEUE_WAIT_CUTOFF 5
```
This is used when we add an onionskin to the qu...Our onion queue code, using the CPU thread pool, has this value hardcoded:
```
/** 5 seconds on the onion queue til we just send back a destroy */
#define ONIONQUEUE_WAIT_CUTOFF 5
```
This is used when we add an onionskin to the queue, we will drop any requests that has been longer than that in the queue by sending a `DESTROY`.
There is also a torrc option named `MaxOnionQueueDelay` that behaves a bit differently. If it takes tor more time than that value to process an ntor, reject it.
Both of these should be consensus parameters because they can affect strongly how our relays behave in times of load or attack like at the moment. For instance, under the DoS conditions of the network, it is possible (unproven) that extending `MaxOnionQueueDelay` to a longer wait time could result in less overload from our relays. But, this is a torrc option meaning that if not all 6000 relays update at once, we might have this partitioning problem.
If one group of the network sets that value higher leading to more room to handle onionskins, it means that these relays will have a higher CBT value which would transition circuit creation away from them to more overloaded relays.
If the network all at once change that value, CBT should in theory remains uniform for all path but just that all the sudden, circuit creation fails less but takes more time.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40676ExitPolicy should apply to already established outbound connections (with a c...2023-08-25T16:55:41ZcypherpunksExitPolicy should apply to already established outbound connections (with a config option, off by default)To reduce the impact of tor running out of free TCP source ports (see pending comment in #26646) we added a reject entry for the destination causing most outbound TCP connections to the ExitPolicy and restarted tor.
```
ExitPolicy reje...To reduce the impact of tor running out of free TCP source ports (see pending comment in #26646) we added a reject entry for the destination causing most outbound TCP connections to the ExitPolicy and restarted tor.
```
ExitPolicy reject 1.2.3.4:* <<<< added to avoid outbound connections to this target
ExitPolicy accept *:80
ExitPolicy accept *:443
ExitPolicy reject *:*
```
Expected: Tor should not create any connections to 1.2.3.4
Even after changing the torrc and restarting tor we see established TCP connections to 1.2.3.4,
this is unexpected.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40629Allow ignoring of SIGINT2022-06-23T21:13:51ZtlaAllow ignoring of SIGINT### Summary
Add an option (.e.g `--IgnoreSigint 1`) which allows to ignore `SIGINT`.
iOS has a feature which enables apps to keep running in the background for a certain amount of time:
https://developer.apple.com/documentation/uikit/...### Summary
Add an option (.e.g `--IgnoreSigint 1`) which allows to ignore `SIGINT`.
iOS has a feature which enables apps to keep running in the background for a certain amount of time:
https://developer.apple.com/documentation/uikit/uiapplication/1623031-beginbackgroundtask
However, even when we're making use of that, iOS is sending `SIGINT` to the app process, as soon as the user swipes away the app. (Sends it into background.)
Tor is currently hardcoded to stop working, when it receives that `SIGINT`:
https://gitlab.torproject.org/tpo/core/tor/-/blob/main/src/app/main/main.c#L223-228
### What is the expected behavior?
When the mentioned configuration option is set, Tor just ignores the `SIGINT` and continues running, to enable processing in the background.Tor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40870Client-side Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in co...2023-10-18T14:40:19ZMike PerryClient-side Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_legWe got a driveby log barf from a cypherpunks:
```
TorProvider: [Tor warning] Bug: Tor 0.4.8.7 (git-bf5e234d): Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at conflux.c:565. (Stack trace not avail...We got a driveby log barf from a cypherpunks:
```
TorProvider: [Tor warning] Bug: Tor 0.4.8.7 (git-bf5e234d): Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at conflux.c:565. (Stack trace not available) (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_pick_first_leg: Bug: Matching client sets: (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_log_set: Bug: Conflux 6EB994986FCDAA7A: 0 linked, 0 launched. Delivered: 692335; teardown: 0; Current: 0000000000000000, Previous: 0000000000000000 (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_pick_first_leg: Bug: Matching server sets: (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_log_set: Bug: Conflux 6EB994986FCDAA7A: 0 linked, 0 launched. Delivered: 692335; teardown: 0; Current: 0000000000000000, Previous: 0000000000000000 (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_pick_first_leg: Bug: End conflux set dump (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] circuit_get_package_window: Bug: Conflux has no circuit to send on. Circuit 000001896a32af00 idx 5 marked at line circuitlist.c:1693 (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] tor_bug_occurred_: Bug: conflux.c:565: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
```
This looks like a client-side issue. The strange thing is that unlike #40842, this is client-side (Tor Browser, I believe). Additionally, `in_full_teardown` is false, but both the `curr_leg` and the `prev_leg` are NULL, *and* the set was previously used to receive a bunch of data (delivered 692335 cells, as the log says).
The mark for close line is in `circuit_unlink_all_from_channel()`.
What I think might be happening is some kind of shutdown race, where the `curr_leg` is quickly nulled out via `linked_circuit_free()` (which does *not* set `in_full_teardown` -- this could be a bug), but the `prev_leg` is still going through the channel teardown path and getting marked first, and then hitting this situation, without `in_full_teardown` set.
Other than shutdown, I can't think of any other ways that the `curr_leg` could get all the way freed and NULL, without setting `in_full_teardown`. I suppose it is also possible that there were previous warn logs related to this that they omitted.
Unfortunately, the cypherpunk disappeared, and we have no idea if their Tor Browser was having connectivity issues, or if they restarted their Tor, or what else might be a factor.
So we need another instance from a helpful reporter. Ideally one that also has a backtrace (I think this must be windows, because the backtrace is missing).Tor: 0.4.8.x-post-stableMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40861Look into build failures on modern Debian for CI on main2024-03-20T14:33:46ZAlexander Færøyahf@torproject.orgLook into build failures on modern Debian for CI on main@weasel reported a build issue on i386 with test failures. Have a look at:
```
180923 19:04:59 + weasel: sandbox/openat_filename: [forking] OK
180923 19:05:00 + weasel: sandbox/opendir_dirname: [forking]
180923 19:05:00 + ...@weasel reported a build issue on i386 with test failures. Have a look at:
```
180923 19:04:59 + weasel: sandbox/openat_filename: [forking] OK
180923 19:05:00 + weasel: sandbox/opendir_dirname: [forking]
180923 19:05:00 + weasel: FAIL ../src/test/test_sandbox.c:266: opendir: Operation not permitted [1]
180923 19:05:00 + weasel: [opendir_dirname FAILED]
180923 19:05:00 + weasel: sandbox/chmod_filename: [forking] OK
180923 19:05:00 + weasel: sandbox/chown_filename: [forking] OK
180923 19:05:02 + weasel: hm.
180923 19:05:17 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367821
180923 19:05:59 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367812
180923 19:06:00 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367811
180923 19:06:04 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367808
180923 19:06:06 + weasel: they all do that
180923 19:06:35 trinity-1686: maybe related to core/tor!446 ?
180923 19:06:35 -tor:#tor-dev- https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/446 - Fix sandbox on AArch64, RISC-V
180923 19:06:53 + weasel: i386
chat and mess w it
180923 19:09:48 + ahf: weasel: it's only impacting 0.4.9, right?
180923 19:09:56 + ahf: as in, main - not your 0.4.8 builds
180923 19:10:44 + weasel: maybe
180923 19:11:14 + weasel: if that's likely, then I'll push the signed tag and see how those go
180923 19:11:43 + ahf: 0.4.9 is main, so things can break there a bit more frequently than it should on any of the release-* branches
180923 19:12:34 + weasel: pushed the tag, let's see how that pipeline goes
180923 19:12:43 + ahf: oki, let us know how it goes!
180923 19:13:04 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/pipelines/104953 you can know as soon as I know :)
180923 19:13:34 + ahf: i am not going to monitor a build log for a hopeful success here - i am deep into other things in parallel
180923 19:41:39 + ahf: ../src/test/test_bt_cl.c: In function 'crash':
180923 19:41:40 + ahf: ../src/test/test_bt_cl.c:46:24: warning: null pointer dereference [-Wnull-dereference] 46 | *(volatile int *)0 = 0;
180923 19:41:43 + ahf: it's not wrong
180923 20:01:27 + weasel: 0.4.8 did build
180923 20:03:55 + ahf: so 0.4.9 has some build issue on ... all your debian's?
180923 20:06:57 + weasel: just i386 on more modern ones
180923 20:09:45 + ahf: so i386 on modern debian?
180923 20:09:55 + ahf: thank you, weasel
180923 20:09:59 + ahf: creating a ticket
```Tor: 0.4.8.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org