The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-24T13:15:59Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5271add log messages when a hidden service consistently doesn't have any preempti...2020-07-24T13:15:59ZRoger Dingledineadd log messages when a hidden service consistently doesn't have any preemptive circuit readyWe basically just made up numbers for how many preemptive circuits a hidden service should have. Are popular hidden services mis-tuned?
A first step to answering this question might be to teach Tors to notice if they are too often needi...We basically just made up numbers for how many preemptive circuits a hidden service should have. Are popular hidden services mis-tuned?
A first step to answering this question might be to teach Tors to notice if they are too often needing to build a new circuit on the spot. They could log when it happens, and the operators could let us know they see the log and encourage us to make these parameters into config options.
Unless there's a better way to get started?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5238“Got a certificate for $DIRAUTH, but we already have it.” should not be a war...2020-06-27T14:06:45ZRobert Ransom“Got a certificate for $DIRAUTH, but we already have it.” should not be a warningA bridge operator reported the following message on tor-talk:
> `[warn] Got a certificate for dizum, but we already have it. Maybe they haven't updated it. Waiting for a while.`
It's not something that normal users should care about, s...A bridge operator reported the following message on tor-talk:
> `[warn] Got a certificate for dizum, but we already have it. Maybe they haven't updated it. Waiting for a while.`
It's not something that normal users should care about, so we shouldn't show it to them (i.e. we should downgrade it to info level). (Perhaps it should stay at notice level on dirauths, though.)Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5235550 Hz warn-level log spam on dirauth (“[warn] Weighted bandwidth is 0.000000...2020-06-27T14:06:45ZLinus Nordberglinus@torproject.org550 Hz warn-level log spam on dirauth (“[warn] Weighted bandwidth is 0.000000...”)maatuska sees
[warn] Weighted bandwidth is 0.000000 in node selection for rule weight as directory
_very_ often. Today, it's been seen 19602 times.
At one point today I saw 7690 of these in 14 seconds. That's about 550 Hz.
rr...maatuska sees
[warn] Weighted bandwidth is 0.000000 in node selection for rule weight as directory
_very_ often. Today, it's been seen 19602 times.
At one point today I saw 7690 of these in 14 seconds. That's about 550 Hz.
rransom says it might be because all dirauths have bandwidth weight 0
and that bwauths sets dirauths to 0. Haven't yet checked what more it
takes to end up here though.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5179Typo in crypto_hmac_sha256 documentation comment2020-06-27T14:06:47ZRobert RansomTypo in crypto_hmac_sha256 documentation commentSee my typo-fix-2012-02-20-01 branch for a fix on master.See my typo-fix-2012-02-20-01 branch for a fix on master.Tor: 0.2.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5170crypto_pk_get_digest (et al.?) use i2d_RSAPublicKey obsoletely2020-06-27T14:06:48ZRobert Ransomcrypto_pk_get_digest (et al.?) use i2d_RSAPublicKey obsoletely`i2d_RSAPublicKey` now supports (in OpenSSL 0.9.7 or later, so in all OpenSSL versions we support) allocating its own output buffer (using `OPENSSL_malloc`). Is this feature worth using in `crypto_pk_get_digest` (and some other function...`i2d_RSAPublicKey` now supports (in OpenSSL 0.9.7 or later, so in all OpenSSL versions we support) allocating its own output buffer (using `OPENSSL_malloc`). Is this feature worth using in `crypto_pk_get_digest` (and some other functions which call `i2d_RSAPublicKey` twice to allocate a _temporary_ buffer)?
(See the `i2d_X509(3ssl)` man page.)Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5129Avoid fcntl(O_NONBLOCK) calls on Linux2020-06-27T14:06:49ZNick MathewsonAvoid fcntl(O_NONBLOCK) calls on LinuxWe already use the SOCK_CLOEXEC extesion to socket/accept4/open/socketpair on Linux so that we can create a socket/fd and make it close-on-exec in a single syscall. In 0.2.4.x, we might want to do the same for opening a nonblocking soc...We already use the SOCK_CLOEXEC extesion to socket/accept4/open/socketpair on Linux so that we can create a socket/fd and make it close-on-exec in a single syscall. In 0.2.4.x, we might want to do the same for opening a nonblocking socket.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5124Get rid of the last 'opt' strings in descriptors?2020-06-27T14:06:50ZRoger DingledineGet rid of the last 'opt' strings in descriptors?For a long time now 'opt' has been optional. So long that we can drop it from descriptor lines, yes?
I see it in "protocols", "fingerprint", "extra-info-digest", "hidden-service-dir".For a long time now 'opt' has been optional. So long that we can drop it from descriptor lines, yes?
I see it in "protocols", "fingerprint", "extra-info-digest", "hidden-service-dir".Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5005False statement in ClientOnly man-page description2021-07-22T16:26:23ZRobert RansomFalse statement in ClientOnly man-page descriptionThe man page states: “Tor is pretty smart at figuring out whether you are reliable and high-bandwidth enough to be a useful server.” This statement is false.
Reported by XD.The man page states: “Tor is pretty smart at figuring out whether you are reliable and high-bandwidth enough to be a useful server.” This statement is false.
Reported by XD.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4998MyFamily as a list2020-06-27T14:06:55Zweasel (Peter Palfrader)MyFamily as a listHi,
MyFamily currently is a config string. It'd be nice if it was a line list like RecommendedVersions as that would make configuration files a bit more readable.Hi,
MyFamily currently is a config string. It'd be nice if it was a line list like RecommendedVersions as that would make configuration files a bit more readable.Tor: 0.3.1.x-finalJigsaw52Jigsaw52https://gitlab.torproject.org/tpo/core/tor/-/issues/4991Use standard windows-detection macros2021-09-16T14:35:59ZNick MathewsonUse standard windows-detection macrosIn our code, we mostly use MS_WINDOWS to detect windows; we sometimes use WIN32 to detect windows; and we sometimes use _WIN32.
_WIN32 is standard; WIN32 is obsolete; MS_WINDOWS is our own silliness. Let's be consistent and standard a...In our code, we mostly use MS_WINDOWS to detect windows; we sometimes use WIN32 to detect windows; and we sometimes use _WIN32.
_WIN32 is standard; WIN32 is obsolete; MS_WINDOWS is our own silliness. Let's be consistent and standard and just use WIN32.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4817Control port authentication failures don't differentiate failure types2020-06-27T14:07:03ZDamian JohnsonControl port authentication failures don't differentiate failure typesThe control-spec has a couple status codes for authentication failures...
514 Authentication required
515 Bad authentication
The 515 status is used for both rejection of the authentication credentials and of the authentication method e...The control-spec has a couple status codes for authentication failures...
514 Authentication required
515 Bad authentication
The 515 status is used for both rejection of the authentication credentials and of the authentication method entirely. For instance...
Rejected Credentials:
```
AUTHENTICATE "blarg"
515 Authentication failed: Password did not match HashedControlPassword value from configuration
Connection closed by foreign host.
```
Rejected Authentication Method:
```
AUTHENTICATE
515 Authentication failed: Password did not match HashedControlPassword value from configuration. Maybe you tried a plain text password? If so, the standard requires that you put it in double quotes.
Connection closed by foreign host.
```
This means that controllers need to read the message to translate these responses into an exception type. Needless to say this isn't great since it leads to sadness if we change or provide localization of the messages.
In stem's case I provide a warning in the pydocs and attempt to use the message...
```
"""
Authenticates to a control socket that uses a password (via the
HashedControlPassword torrc option). Quotes in the password are escaped.
If authentication fails tor will disconnect and we'll make a best effort
attempt to re-establish the connection. This may not succeed, so check
is_alive() before using the socket further.
For general usage use the authenticate() function instead.
note: If you use this function directly, rather than authenticate(), we may
mistakenly raise a PasswordAuthRejected rather than IncorrectPassword. This
is because we rely on tor's error messaging which is liable to change in
future versions.
"""
...
# if we got anything but an OK response then error
if str(auth_response) != "OK":
try: control_socket.connect()
except: pass
# all we have to go on is the error message from tor...
# Password did not match HashedControlPassword value value from configuration...
# Password did not match HashedControlPassword *or*...
if "Password did not match HashedControlPassword" in str(auth_response):
raise IncorrectPassword(str(auth_response), auth_response)
else:
raise PasswordAuthRejected(str(auth_response), auth_response)
```
https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/connection.py#l468
I do this for both the authenticate_password and authenticate_cookie functions. In general this won't be very visible to library users since they'll usually use the authenticate() function instead, which has a PROTOCOLINFO response so it doesn't have this issue.
Feel free to resolve this as 'wont fix'. This isn't an issue if controller users do PROTOCOLINFO first, and the AUTHENTICATE function has no notion of the authentication type being attempted so it would be difficult for tor to differentiate those issues, even if it wanted to. Mostly just noting a minor gotcha I encountered while writing stem. :)
Cheers! -DamianTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4816Request: add count to "[warn] Your computer is too slow..."2020-06-27T14:07:03ZTracRequest: add count to "[warn] Your computer is too slow..."Seen with Tor v0.2.2.35:
"[warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy."
It would be helpful if...Seen with Tor v0.2.2.35:
"[warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy."
It would be helpful if the number of connections that occasion this warning be stated in the message. I suggest replacing the text "this many" with an actual number.
Thanks.
**Trac**:
**Username**: tmpname0901Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4803Log message contains typo2020-06-27T14:07:03ZRobert RansomLog message contains typo```
Dec 29 20:12:55.079 [warn] Before Tor can create a control socket in "/var/run/tor/control", the directory "/var/run/tor" needs to exist, and to be accessible only by the user and group account that is running Tor. (On some Unix sys...```
Dec 29 20:12:55.079 [warn] Before Tor can create a control socket in "/var/run/tor/control", the directory "/var/run/tor" needs to exist, and to be accessible only by the user and group account that is running Tor. (On some Unix systems, anybody who can list a socket can conect to it, so Tor is being careful.)
```
`s/conect/connect/`Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4710Tor does not convert TCP socket exhaustion to END_STREAM_REASON_RESOURCELIMIT2020-06-27T14:07:08ZMike PerryTor does not convert TCP socket exhaustion to END_STREAM_REASON_RESOURCELIMITMoritz has reported the appearance of warns to the effect of "[warn] Error binding network socket: Address already in use" recently as a result of the PID feedback experiment. We could implement a feedback cap for nodes that hit this exh...Moritz has reported the appearance of warns to the effect of "[warn] Error binding network socket: Address already in use" recently as a result of the PID feedback experiment. We could implement a feedback cap for nodes that hit this exhaustion, if we could detect it using stream end reasons (legacy/trac#4709).
However, in errno_to_stream_end_reason(), it looks like Tor does not have a case covering "Address already in use" (EADDRINUSE and possibly also EADDRNOTAVAIL), which seems to be the errno Moritz's Ubuntu server is choosing when it runs out of TCP source ports.
I'd add these cases myself, but I am not sure if it should be an E_CASE or S_CASE, and I'm also not sure if the TCP source port exhaustion errno is always the same EADDRINUSE across all platforms, or just on Linux. It seems like a weird choice to me.Tor: 0.2.3.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4698MapAddress should be able to map from invalid .onion names2020-06-27T14:07:09ZTracMapAddress should be able to map from invalid .onion namesWhen one tries to access example.onion after `MapAddress example.onion duskgytldkxiuqc6.onion` has been added to the configuration file, Tor logs a warning, `Invalid onion hostname [scrubbed]; rejecting`.
**Trac**:
**Username**: katmagicWhen one tries to access example.onion after `MapAddress example.onion duskgytldkxiuqc6.onion` has been added to the configuration file, Tor logs a warning, `Invalid onion hostname [scrubbed]; rejecting`.
**Trac**:
**Username**: katmagicTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4677master won't build without V2_HANDSHAKE_SERVER2020-06-27T14:07:10ZGeorge Kadianakismaster won't build without V2_HANDSHAKE_SERVERmaster won't build without `V2_HANDSHAKE_SERVER`:
```
tortls.c:1525:40: error: ‘tor_tls_debug_state_callback’ undeclared (first use in this function)
tortls.c:1525:40: note: each undeclared identifier is reported only once for each funct...master won't build without `V2_HANDSHAKE_SERVER`:
```
tortls.c:1525:40: error: ‘tor_tls_debug_state_callback’ undeclared (first use in this function)
tortls.c:1525:40: note: each undeclared identifier is reported only once for each function it appears in
```
This happens because without `V2_HANDSHAKE_SERVER`, `tor_tls_debug_state_callback` is not defined and it's not visible when `tor_tls_new()` tries to do:
```
SSL_set_info_callback(result->ssl, tor_tls_debug_state_callback);
```
This bug was introduced in `410e440a8d40e556cc445a1ecc6a8ed4109434b6`, and simply always defining `tor_tls_debug_state_callback` (and not only when V2_HANDSHAKE_SERVER`) should fix it.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4664./autogen.sh puts stuff on stderr2020-06-27T14:07:11ZSebastian Hahn./autogen.sh puts stuff on stderrinside autogen.sh, we call autoreconf -ivf. The -v flag means verbose reports, which are basically just "going to dir x, calling application y" on stderr. This is pretty useless, and for some scripts I'd like to be able to silence the ou...inside autogen.sh, we call autoreconf -ivf. The -v flag means verbose reports, which are basically just "going to dir x, calling application y" on stderr. This is pretty useless, and for some scripts I'd like to be able to silence the output except for error conditions. Can we simply take out the -v here without bad stuff happening?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4653Use SSL_state_string_long() instead of homebrewed ssl_state_to_string()2020-06-27T14:07:12ZGeorge KadianakisUse SSL_state_string_long() instead of homebrewed ssl_state_to_string()OpenSSL has two functions to get a string version of the SSL state,
`SSL_state_string_long()` and `SSL_state_string()`.
We can use these instead of the homebrewed ssl_state_to_string() and the tortls_state.h file.OpenSSL has two functions to get a string version of the SSL state,
`SSL_state_string_long()` and `SSL_state_string()`.
We can use these instead of the homebrewed ssl_state_to_string() and the tortls_state.h file.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4645Deprecate and remove is_internal_IP2020-06-27T14:07:13ZRobert RansomDeprecate and remove is_internal_IPTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4536DirAllowPrivateAddresses: Inconsistency in code2020-06-27T14:07:21ZTracDirAllowPrivateAddresses: Inconsistency in code```
V(DirAllowPrivateAddresses, BOOL, NULL),
```
Must be 0, not a NULL.
**Trac**:
**Username**: troll_un```
V(DirAllowPrivateAddresses, BOOL, NULL),
```
Must be 0, not a NULL.
**Trac**:
**Username**: troll_unTor: 0.2.3.x-final