The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:08:48Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2363evdns_base_resolve_* macros are bogus2020-06-27T14:08:48ZRobert Ransomevdns_base_resolve_* macros are bogus> 2011-01-08 08:59 <lodger> non-libevent2's evdns_resolve_*() funcs returns (1) for error. Tor-alpha waiting for -1 as for libevent2 case. dns.c defines evdns_base_resolve_*() errorly for non-libevent2 case.> 2011-01-08 08:59 <lodger> non-libevent2's evdns_resolve_*() funcs returns (1) for error. Tor-alpha waiting for -1 as for libevent2 case. dns.c defines evdns_base_resolve_*() errorly for non-libevent2 case.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2442A bunch of hidden service warnings should be protocol warnings2020-06-27T14:08:45ZSebastian HahnA bunch of hidden service warnings should be protocol warningsWe've had quite a few reports about log messages such as:
```
Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 5 seconds ago.
```
and
```
INTRODUCE2 cell is too old. Discarding
``...We've had quite a few reports about log messages such as:
```
Possible replay detected! We received an INTRODUCE2 cell with same first part of Diffie-Hellman handshake 5 seconds ago.
```
and
```
INTRODUCE2 cell is too old. Discarding
```
These are messages that an operator can't do anything about, and they should be in the protocol warnings category instead.Tor: 0.2.2.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2475Split SIZE_T_CEILING, SSIZE_T_CEILING2020-06-27T14:08:43ZNick MathewsonSplit SIZE_T_CEILING, SSIZE_T_CEILINGFor good C practice, we should have separate signed and unsigned values for the ssize_t and size_t ceilings, and avoid signed-to-unsigned comparisons. See comments in bug legacy/trac#2337 for background.
(We don't want to just make SIZ...For good C practice, we should have separate signed and unsigned values for the ssize_t and size_t ceilings, and avoid signed-to-unsigned comparisons. See comments in bug legacy/trac#2337 for background.
(We don't want to just make SIZE_T_CEILING unsigned and use it everwhere, since comparing a ssize_t to an unsigned SIZE_T_CEILING is just as broken as comparing a size_t to a signed SIZE_T_CEILING.)https://gitlab.torproject.org/tpo/core/tor/-/issues/2503Tor describes HTTPS proxy 403 errors as 'unexpected status code'2020-06-27T14:08:42ZRobert RansomTor describes HTTPS proxy 403 errors as 'unexpected status code'When Tor tries to connect to a relay or bridge through an HTTPS proxy, and the CONNECT request is rejected with a 403 error code (meaning 'Forbidden'), Tor describes the 403 response as an 'unexpected status code'. 403 errors should be ...When Tor tries to connect to a relay or bridge through an HTTPS proxy, and the CONNECT request is rejected with a 403 error code (meaning 'Forbidden'), Tor describes the 403 response as an 'unexpected status code'. 403 errors should be logged with a more correct/useful message, and there are probably other error codes we should describe better as well.
For 403 errors, we could log `"... proxy refused to allow connection to %s"`.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2507It's probably not spelled "NATD"2020-06-27T14:08:42ZNick MathewsonIt's probably not spelled "NATD"We've been spelling it "NATD" throughout the code and documentation, but the BSD manpage calls it "natd". We might as well adopt their capitalization.We've been spelling it "NATD" throughout the code and documentation, but the BSD manpage calls it "natd". We might as well adopt their capitalization.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2571warn if entrynodes set but useentrynodes 02020-06-27T14:08:40ZRoger Dingledinewarn if entrynodes set but useentrynodes 0legacy/trac#2566 got bitten by setting entrynodes on their torperf run but torperf sets useentrynodes to 0 so it can approximate the behavior of every user.
Seems like we should warn the user if they do this.legacy/trac#2566 got bitten by setting entrynodes on their torperf run but torperf sets useentrynodes to 0 so it can approximate the behavior of every user.
Seems like we should warn the user if they do this.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2616inconsistency in routerlist_add_family()2020-06-27T14:08:39ZRoger Dingledineinconsistency in routerlist_add_family()routerlist_add_family() is supposed to put the family members of "router" into "sl". There are three rules: 1) If they're in the same /16 network space. 2) If the descriptors declare they're in the same family. 3) If the user's NodeFamil...routerlist_add_family() is supposed to put the family members of "router" into "sl". There are three rules: 1) If they're in the same /16 network space. 2) If the descriptors declare they're in the same family. 3) If the user's NodeFamilies torrc option lists the router in a family.
In cases 1 and 2, they avoid listing "router" in the returned smartlist. Case 3 though happily includes it.
This typically means that the caller of routerlist_add_family() ends up with a smartlist with "router" in it twice, since most callers of the function start by adding router to the smartlist first. My patch to legacy/trac#2403 is the first time we do it differently. I think it's safe in that particular case. But we should still make the behavior consistent.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2752Tor limits HttpProxyAuthenticator values to 48 characters2020-06-27T14:08:32ZTracTor limits HttpProxyAuthenticator values to 48 charactersBeing under a proxy, I've tried to use TOR with vidalia.
However, when I try to configure Vidalia with my proxy setting, I got the error: "Vidalia was unable to apply your Network settings to Tor. Unacceptable option value: HttpProxyAuth...Being under a proxy, I've tried to use TOR with vidalia.
However, when I try to configure Vidalia with my proxy setting, I got the error: "Vidalia was unable to apply your Network settings to Tor. Unacceptable option value: HttpProxyAuthenticator is too long (>= 48 chars)." Indeed, I'm using a login of 41 chars + a password of 10 chars.
How to solve this problem?
**Trac**:
**Username**: dudumomoTor: 0.2.2.x-finalTomas ToucedaTomas Toucedahttps://gitlab.torproject.org/tpo/core/tor/-/issues/2767Another possible directory-handling bug2020-06-27T14:08:31ZRobert RansomAnother possible directory-handling bug> 2011-03-16 09:58 <tor-internal> parse_http_url() allows alone GET or POST, "If it's well-formed, strdup the second \%s" says that it's incorrect. second "eat_whitespace_no_nl" leaves nl, should be "eat_whitespace".> 2011-03-16 09:58 <tor-internal> parse_http_url() allows alone GET or POST, "If it's well-formed, strdup the second \%s" says that it's incorrect. second "eat_whitespace_no_nl" leaves nl, should be "eat_whitespace".Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2797Fix redundant checks around routerset_contains_XYZ()2020-06-27T14:08:31ZNick MathewsonFix redundant checks around routerset_contains_XYZ()The routerset_contains_foo() functions currently accept "NULL" in place of a routerset argument, with "NULL" denoting an empty routerset. (IOW, routerset_contains_node(NULL, node) always returns false.)
But our code acts like we don't ...The routerset_contains_foo() functions currently accept "NULL" in place of a routerset argument, with "NULL" denoting an empty routerset. (IOW, routerset_contains_node(NULL, node) always returns false.)
But our code acts like we don't know this: in lots of places, we say stuff like
```
if (set && routerset_contains_node(set, node)) {
}
```
which is redundant and silly. We can remove the "set &&" with no ill effect.
Note that this shouldn't be confused with
```
if (!set || routerset_contains_node(set, node)) {
}
```
which is how we say, "in this case, NULL means 'all nodes are included.'"
I'm tagging this as a ticket for 0.2.3.x. We should only do this once 0.2.2 has settled down a little more though, since the merges are likely to be conflicty given the router->node transition.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2893Tor controller requires space in 'authenticate' command2020-06-27T14:08:30ZRoger DingledineTor controller requires space in 'authenticate' command```
arma@last-request:~/old/torgit/torspec/proposals$ telnet localhost 9051
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
authenticate
250 OK
quit
250 closing connection
Connection closed by foreign ...```
arma@last-request:~/old/torgit/torspec/proposals$ telnet localhost 9051
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
authenticate
250 OK
quit
250 closing connection
Connection closed by foreign host.
arma@last-request:~/old/torgit/torspec/proposals$ nc localhost 9051
authenticate
551 Invalid quoted string. You need to put the password in double quotes.
arma@last-request:~/old/torgit/torspec/proposals$ nc localhost 9051
authenticate ""
250 OK
quit
250 closing connection
```
Setting up logging on Tor's side in handle_control_authenticate():
```
log_notice(LD_CONTROL, "'%s'", body);
```
in the first case I get
```
Apr 11 16:39:13.633 [notice] '
'
```
and in the second case I get
```
Apr 11 16:39:23.258 [notice] ''
```
It looks like that function is checking
```
} else if (TOR_ISSPACE(body[0])) {
password = tor_strdup("");
password_len = 0;
}
```
So Tor demands that you have some sort of whitespace before your newline. That runs counter to our spec:
```
Wherever CRLF is specified to be accepted from the controller, Tor MAY also
accept LF. Tor, however, MUST NOT generate LF instead of CRLF.
Controllers SHOULD always send CRLF.
```Tor: 0.2.3.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2914Tor should truncate log file if loglevel < notice2022-06-17T16:09:19ZMike PerryTor should truncate log file if loglevel < noticeA lot of relay operators run tor from git for various reasons. These relay operators don't get the advantage of distribution log rotation, and can unknowingly leave tor running at low log level for long periods while running test branche...A lot of relay operators run tor from git for various reasons. These relay operators don't get the advantage of distribution log rotation, and can unknowingly leave tor running at low log level for long periods while running test branches. In some cases, SafeLogging may also be disabled.
Presumably, since they are running git, they are upgrading often. Based on this assumption, an easy fix should be to just change the default log file open mode from O_APPEND to O_TRUNC if the loglevel is below notice, and/or if SafeLogging is off.
Of course, a better fix is to implement our own log rotation. I don't think the corner case is that important. It is a non-default config that makes it risky** in the first place.
Thanks to Marcia Hofmann @ EFF for pointing this out.
** (The reason it is risky is not because logs are terribly dangerous to anonymity in their current form, but moreso because logs can be such a false path due to the multiplexing of circuits over TLS.)https://gitlab.torproject.org/tpo/core/tor/-/issues/2936Tor specs say 'server' when they often mean 'relay'2020-06-27T14:08:28ZRoger DingledineTor specs say 'server' when they often mean 'relay'Long ago we shifted the terminology from 'server' to 'relay' in most cases. The specs still use the old terms. That situation probably confuses readers.Long ago we shifted the terminology from 'server' to 'relay' in most cases. The specs still use the old terms. That situation probably confuses readers.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2967bad pidfile handling on ENOSPC2020-07-24T12:40:54Zintrigeribad pidfile handling on ENOSPCThe Tor daemon was reported two years ago, as [Debian bug #514616](http://bugs.debian.org/514616), to behave quite badly when it does not manage to write its pidfile because of a full filesystem.
Some discussion between the bug reporter...The Tor daemon was reported two years ago, as [Debian bug #514616](http://bugs.debian.org/514616), to behave quite badly when it does not manage to write its pidfile because of a full filesystem.
Some discussion between the bug reporter and Peter happened there and is probably a good starting point to fix this bug.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3079circuit_list_path_impl() says 'exit' for internal circs2020-06-27T14:08:22ZRoger Dingledinecircuit_list_path_impl() says 'exit' for internal circsRelated to legacy/trac#1090:
```
tor_asprintf(&cp, "%s%s circ (length %d%s%s):",
circ->build_state->is_internal ? "internal" : "exit",
circ->build_state->need_uptime ? " (high-uptime)" : "",
...Related to legacy/trac#1090:
```
tor_asprintf(&cp, "%s%s circ (length %d%s%s):",
circ->build_state->is_internal ? "internal" : "exit",
circ->build_state->need_uptime ? " (high-uptime)" : "",
circ->build_state->desired_path_len,
circ->_base.state == CIRCUIT_STATE_OPEN ? "" : ", exit ",
circ->_base.state == CIRCUIT_STATE_OPEN ? "" :
(nickname?nickname:"*unnamed*"));
```
That second 'exit' needs to say something else for internal circs. E.g, "last hop".Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3155Single Underscore in Option Name2020-06-27T14:08:20ZDamian JohnsonSingle Underscore in Option NameConfig options either start with zero or double underscores with a single exception...
```
>>> conn.getInfo("version")
'0.2.2.23-alpha (git-b85eb949b528f4d7)'
>>> print "\n".join(sorted(conn.getInfo("config/names", "").split("\n")))
......Config options either start with zero or double underscores with a single exception...
```
>>> conn.getInfo("version")
'0.2.2.23-alpha (git-b85eb949b528f4d7)'
>>> print "\n".join(sorted(conn.getInfo("config/names", "").split("\n")))
...
WarnPlaintextPorts CommaList
WarnUnsafeSocks Boolean
_UsingTestNetworkDefaults Boolean
__AllDirActionsPrivate Boolean
__DisablePredictedCircuits Boolean
__HashedControlSessionPassword LineList
__LeaveStreamsUnattached Boolean
__ReloadTorrcOnSIGHUP Boolean
```
I asked about this on irc, but I'm not clear from Robert's response if this means that '_UsingTestNetworkDefaults' actually shouldn't be exposed to the controller.
08:12 < atagar> I'm finding that most private options start with a double underscore, but in one case it's a single underscore... [bit removed since trac chokes on the double underscores]
08:12 < atagar> is this a mistake?
08:13 < rransom> _UsingTestNetworkDefaults is a fake option.
08:13 < rransom> The double-underscore options are for use by controllers.
08:18 < atagar> Fake option? Not following - the single underscore has some special meaning?
08:18 < rransom> atagar: _UsingTestNetworkDefaults is clobbered within Tor every time it processes its options.
08:19 < rransom> The double-underscore options are actual options that can be set from outside Tor.
08:20 < atagar> Is it right then for _UsingTestNetworkDefaults to be presented via 'GETINFO config/names'? I'm pretty sure this makes it user setable.
08:20 < atagar> yup, it does
Feel free to close if presenting the _UsingTestNetworkDefaults option this way is intended (though I'd be a little curious then what the single underscore should signify for controllers).
Cheers! -DamianTor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3175smartlist_string_num_isin's buffer is too short2020-06-27T14:08:19ZRobert Ransomsmartlist_string_num_isin's buffer is too short`smartlist_string_num_isin` converts an int to a 15-character or shorter string. Its 16-byte buffer is not long enough to handle all 64-bit ints (-2^63^ is 20 characters long, so the buffer would need to be at least 21 bytes long).
We ...`smartlist_string_num_isin` converts an int to a 15-character or shorter string. Its 16-byte buffer is not long enough to handle all 64-bit ints (-2^63^ is 20 characters long, so the buffer would need to be at least 21 bytes long).
We currently only use this function for (16-bit) TCP port numbers, so this bug doesn't actually hurt anything, but we shouldn't leave an even slightly incorrect function lying around to bite us later.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3176Spec the max descriptor sizes2021-07-22T16:26:22ZcypherpunksSpec the max descriptor sizesAllowing arbitrarily large descriptors is bad for everyone, because they have to fetch all that data. Tor currently limits descriptors to 200000 bytes, we should actually spec that out tho.Allowing arbitrarily large descriptors is bad for everyone, because they have to fetch all that data. Tor currently limits descriptors to 200000 bytes, we should actually spec that out tho.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3199Refactor periodic events2020-06-27T14:08:19ZNick MathewsonRefactor periodic eventsRight now we invoke a truly huge array of things from second_elapsed_callback() and run_scheduled_events(). There are at least 23 separate static time_t values that we do a comparison against every time a second elapses.
This is a real...Right now we invoke a truly huge array of things from second_elapsed_callback() and run_scheduled_events(). There are at least 23 separate static time_t values that we do a comparison against every time a second elapses.
This is a really goofy way to handle periodic events. Let's refactor this to instead use libevent's timing code. In addition, we could make the timers first-class, so as to allow better introspection of Tor's status wrt each timer.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3241Seeing lots of "crypto error while reading public key from string" on DA2020-07-24T12:48:34ZLinus Nordberglinus@torproject.orgSeeing lots of "crypto error while reading public key from string" on DAI have about 200 of these (in 20 hours) on my DA:
May 18 21:06:05.183 [warn] crypto error while reading public key from string: too long (in asn1 encoding routines:ASN1_get_object)
May 18 21:06:05.183 [warn] crypto error while reading p...I have about 200 of these (in 20 hours) on my DA:
May 18 21:06:05.183 [warn] crypto error while reading public key from string: too long (in asn1 encoding routines:ASN1_get_object)
May 18 21:06:05.183 [warn] crypto error while reading public key from string: bad object header (in asn1 encoding routines:ASN1_CHECK_TLEN)
May 18 21:06:05.183 [warn] crypto error while reading public key from string: nested asn1 error (in asn1 encoding routines:ASN1_D2I_EX_PRIMITIVE)
May 18 21:06:05.183 [warn] crypto error while reading public key from string: nested asn1 error (in asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I)
May 18 21:06:05.183 [warn] crypto error while reading public key from string: ASN1 lib (in PEM routines:PEM_ASN1_read_bio)
May 18 21:06:05.183 [warn] parse error: Couldn't parse public key.
May 18 21:06:05.183 [warn] Error tokenizing router descriptor.
May 18 21:06:05.183 [warn] Error reading extra-info: signature does not match.Tor: unspecified