Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-11-01T17:10:27Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40427enable TCP timestamps on outgoing ORcon2021-11-01T17:10:27ZpseudonymisaTorenable TCP timestamps on outgoing ORcon### Summary
Make use of TCP timestamps, enable it via socks options on outgoing connections. [Defined in RFC 1323](https://datatracker.ietf.org/doc/html/rfc1323#section-4).
Tor could benefit from some better TCP congestion flow control...### Summary
Make use of TCP timestamps, enable it via socks options on outgoing connections. [Defined in RFC 1323](https://datatracker.ietf.org/doc/html/rfc1323#section-4).
Tor could benefit from some better TCP congestion flow control? The Client or relay does not know what TCP congestion algorithm the other peer may use.
> TCP timestamps are enabled by default In Linux kernel.
It was once disabled in some distros, because the bad implementation of timestamp start time was your system uptime and this fingerprinting could leak your uptime on every connection. This was fixed 2 decades ago. So why not use it now for all and not only some? All Tor Connection should look most identical for fingerprinting reasons.
Why not use it? Worst thing to happen is, that it could add 8 extra bytes of TCP header in total.
### What is the expected behavior?
TCP connections should be always enabling timestamps, to make fingerprinting harder.
WiP: [+TCP_TIMESTAMPS.patch](/uploads/fcbb3a72f3cbfdb91eab7b8e26af26f3/+TCP_TIMESTAMPS.patch)Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40418Man page no longer accurate for onion authorization instructions2022-05-09T16:35:19ZnyxnorMan page no longer accurate for onion authorization instructions[2019 TPO docs](https://2019.www.torproject.org/docs/tor-manual.html.en)
Outdated:
> Client Authorization
> Revoking a client can be done by removing their ".auth" file, however the revocation will be in effect only after the tor proce...[2019 TPO docs](https://2019.www.torproject.org/docs/tor-manual.html.en)
Outdated:
> Client Authorization
> Revoking a client can be done by removing their ".auth" file, however the revocation will be in effect only after the tor process gets restarted even if a SIGHUP takes place.
Revoking a key does work with sighup now.Developer portalSilvio RhattoSilvio Rhattohttps://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/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/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/40310CI: Somehow, test_switch_id.sh is failing on 0352021-10-22T13:26:01ZDavid Gouletdgoulet@torproject.orgCI: Somehow, test_switch_id.sh is failing on 035See: https://gitlab.torproject.org/dgoulet/tor/-/pipelines/3132See: https://gitlab.torproject.org/dgoulet/tor/-/pipelines/3132Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40303rate limit a warn message: "[warn] Error binding network socket: Address alre...2021-04-16T14:12:36Ztoralfrate limit a warn message: "[warn] Error binding network socket: Address already in use"It tends to flood the warn.log under certain circumstances.It tends to flood the warn.log under certain circumstances.Tor: 0.4.6.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/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/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/40265Rebuild fallbackdir list January 20212021-04-15T12:51:30ZGeorge KadianakisRebuild fallbackdir list January 2021Tor: 0.4.6.x-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/40217Reproduce Rob's FlashFlood experiment2023-06-08T17:53:42ZMike PerryReproduce Rob's FlashFlood experimentShadow was unable to reproduce the 95th percentile perf degradation for FlashFlood (seen in https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33076#note_2569011).
I suspect this is due to a Tor bug in something that Shadow is ...Shadow was unable to reproduce the 95th percentile perf degradation for FlashFlood (seen in https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33076#note_2569011).
I suspect this is due to a Tor bug in something that Shadow is emulating rather than simulating. DNS is in this category. It could be DNS timeouts due to overload.
We should get some fast machines and reproduce the experiment on Live, with more frequent onionperf measurement, so we can get more datapoints of which relays were involved in the 95th percentile slowdown.
Rob has released code.
Tor branch:
https://github.com/robgjansen/tor/tree/research/speedtest/v1-squashed
Python script to run the experiment:
https://gist.github.com/robgjansen/ebd7f8ba019dbef2af4877122281cf3b
Notes from Rob:
- The git log in the Tor branch has some details.
- Several important items are hard-coded in the python "speedtester" script, e.g., the 2nd hop test relay fingerprints and the path a latest consensus file.
- The 2nd hop test relays should set MaxAdvertisedBandwidth to the minimum allowed value so they are reserved as much as possible for the speed testing.
Rob also gave me the Tor Safety Board submission. I will attach that. He also gave me result files, which I will attach to https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33076 in case we can still figure out the issue from the last run's data.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40206Include the IPv6 address in the descriptor that is going to be tested for sel...2021-01-13T14:53:55Zs7rInclude the IPv6 address in the descriptor that is going to be tested for self reachabilityFor IPv4 we log the address for which we test self reachability. Very useful for debugging.
Since we have IPv6 autodiscovery now, and we try hard to better support IPv6 (yey) we should include in this log line also the IPv6 address that...For IPv4 we log the address for which we test self reachability. Very useful for debugging.
Since we have IPv6 autodiscovery now, and we try hard to better support IPv6 (yey) we should include in this log line also the IPv6 address that is going to be tested for self reachability (if one exists of course and the relay/bridge is not IPv4 only).
Relays / bridges are not marked as running by directory authorities if they advertise an IPv6 address but are not reachable on it, so it makes full sense for the operators to know which address is being tested.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40196Deprecate rust-in-Tor build features for now, recommend arti rust implemntati...2021-01-08T19:52:25ZNick MathewsonDeprecate rust-in-Tor build features for now, recommend arti rust implemntation insteadWe still like Rust, but right now all the good Rust work is happening in @tpo/core/arti
The existing Rust-in-tor build system is just confusing people, and we should probably deprecate it for now. We can return to it if we want to do a...We still like Rust, but right now all the good Rust work is happening in @tpo/core/arti
The existing Rust-in-tor build system is just confusing people, and we should probably deprecate it for now. We can return to it if we want to do arti/tor integration in the future.Tor: 0.4.6.x-freezeNick 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/40172Build failure on macOS on master2021-07-09T17:30:28ZMatthew FinkelBuild failure on macOS on masterIn tpo/applications/tor-browser-build#40139 we documented that Tor Browser Nightly build for macOS is failing when linking tor using `master`. This began failing on 24 or 25 October. I haven't bisected which tor commit (or build change) ...In tpo/applications/tor-browser-build#40139 we documented that Tor Browser Nightly build for macOS is failing when linking tor using `master`. This began failing on 24 or 25 October. I haven't bisected which tor commit (or build change) is causing this. Attached is the latest build log when building commit df1637600469 (tip of master, at build time).
[tor-osx-x86_64.log](/uploads/f83b8ec1bc057c5cd7f8774936b35aa5/tor-osx-x86_64.log)Tor: 0.4.5.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/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/40140Directory authorities should enable ExtendByEd25519ID2020-10-19T21:44:30ZNick MathewsonDirectory authorities should enable ExtendByEd25519IDThis option has been supported since 0.3.0; it is no longer a fingerprinting risk, and should be enabled for everybody.
@tpo/core Any objections, or should I ask dir-auths@ to do this? Do you think we need to do more testing first?This option has been supported since 0.3.0; it is no longer a fingerprinting risk, and should be enabled for everybody.
@tpo/core Any objections, or should I ask dir-auths@ to do this? Do you think we need to do more testing first?Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40121gitlab ci is now out-of-sync between master and maint-0.3.52020-09-22T13:23:44ZNick Mathewsongitlab ci is now out-of-sync between master and maint-0.3.5There are big comments at the head of `.gitlab-ci.yml` and `ci-driver.sh` that say to keep them in sync on all our branches. But they aren't in sync any more.
@dgoulet, can you have a look? I think it's your commits for tracing that b...There are big comments at the head of `.gitlab-ci.yml` and `ci-driver.sh` that say to keep them in sync on all our branches. But they aren't in sync any more.
@dgoulet, can you have a look? I think it's your commits for tracing that broke this property.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org