The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-24T12:40:54Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/2331Possible integer overflows in base32_encode, base32_decode2020-06-27T14:08:49ZRobert RansomPossible integer overflows in base32_encode, base32_decodedoors reports that the loop-termination comparisons in `base32_encode` and `base32_decode` compare indices of type `unsigned int` with bounds of type `size_t`. The loops will never terminate if the upper bounds are greater than `UINT_MA...doors reports that the loop-termination comparisons in `base32_encode` and `base32_decode` compare indices of type `unsigned int` with bounds of type `size_t`. The loops will never terminate if the upper bounds are greater than `UINT_MAX`.
I see two other, more direct integer overflows in those functions:
In `base32_encode`:
```
size_t nbits = srclen * 8;
```
In `base32_decode`:
```
size_t nbits;
...
nbits = srclen * 5;
```
In both functions, `srclen` is a parameter of type `size_t`.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2330SOCKS client cannot handle responses longer than 128 bytes2020-06-27T14:08:50ZRobert RansomSOCKS client cannot handle responses longer than 128 bytesdoors points out that if a SOCKS proxy sends a reply longer than 128 bytes, Tor may never parse the entire reply. (This can happen, for example, if a SOCKS proxy sends an absurdly long `DOMAINNAME` in the `BND.ADDR` field.)doors points out that if a SOCKS proxy sends a reply longer than 128 bytes, Tor may never parse the entire reply. (This can happen, for example, if a SOCKS proxy sends an absurdly long `DOMAINNAME` in the `BND.ADDR` field.)Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2302Controller event for sighup and shutdown2020-06-27T14:08:52ZDamian JohnsonController event for sighup and shutdownA while back Nick and I discussed adding a controller event for sighups. This isn't something that I'll be getting to any time soon but, it would be a nice addition at some point.
10:15 < nickm> atagar: answering on the ticket. thanks f...A while back Nick and I discussed adding a controller event for sighups. This isn't something that I'll be getting to any time soon but, it would be a nice addition at some point.
10:15 < nickm> atagar: answering on the ticket. thanks for the poke
10:23 < nickm> there
10:25 < atagar> thx
10:25 < nickm> BTW, are there a lot of log messages that arm parses?
10:26 < nickm> Are some of them things that should turn into events of some kind?
10:28 < atagar> arm tracks NOTICE events for sighup/shutdown,
NEWDESC/NS/NEWCONSENSUS to updated cached results, and BW as a
heartbeat
10:28 < nickm> So one of these things is not like the others
10:29 < nickm> The content of BW and NEWDESC/NS/NEWCONSENSUS are
explicitly defined parts of the API.
10:30 < nickm> NOTICE stuff is just log messages, and not guaranteed
to have any particular format.
10:30 < atagar> yup
10:30 < nickm> So probably we should have an event for "we got a
signal" or "we're shutting down"
10:30 < nickm> Those both _do_ sound like STATUS_GENERAL events
10:31 < nickm> If we don't have STATUS events for those already, we
should
10:31 < atagar> hmm, I haven't checked - I'll look into it when adding the 'conf changed' event type
10:32 < nickm> maybe write up what the event should look like before
you start hacking ?
10:32 < atagar> Are you thinking a proposal? It would be kinda
short...
10:33 < nickm> If you want. It could also just be in the form of
writing the patch to control-spec.txt before you write the code
10:33 < special> +1 on a control event for signals, especially HUP.
10:36 < nickm> That one should be trivial; just add the right call to signal_callback in main.c. You probably don't want to report signals that Tor ignores, and you'll want to convert signals to names, but other than that, it cake.
10:37 < nickm> shutting down is a little more complicated, since there are a couple of ways to do it
10:37 < nickm> oh, and we'll probably want a way to special-case
trying to flush the controller connection if we're about to shut
down.
10:39 < nickm> Hm. The way we do that now won't work right with
bufferevents. One More Thing To Fix. :pTor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2106Controller can't unset httpsproxy if it doesn't resolve2020-06-27T14:08:58ZRoger DingledineController can't unset httpsproxy if it doesn't resolveIf you use Vidalia to setconf your httpsproxy, Tor will use that httpsproxy. If you're on a laptop though and you shutdown and start up Tor on a different network, where you don't want to be using that httpsproxy (and where it doesn't re...If you use Vidalia to setconf your httpsproxy, Tor will use that httpsproxy. If you're on a laptop though and you shutdown and start up Tor on a different network, where you don't want to be using that httpsproxy (and where it doesn't resolve), Tor won't start. There's no way for the controller to unset the httpsproxy, because the way the controller approach is designed you start up Tor and then setconf the new config choices.
The result: there's no way to stop using an httpsproxy if you're in an environment that can't resolve the one you configured earlier.
See also
https://trac.vidalia-project.net/ticket/303
Is this something that can be fixed inside Tor (e.g. by not failing)? Or do we need to change the controller recommendations to be able to edit your torrc for you before starting Tor? Poor options all around.
I'm not sure if this should be in the Tor Client component or the Vidalia component. Picking Tor for now.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2068Add a guard-status getinfo2020-06-27T14:09:00ZSebastian HahnAdd a guard-status getinfoBridge users should get better feedback about which bridges are up and running, etc. This means controllers need to get an idea about the current status of the bridges as Tor sees it. Just listening to GUARD events isn't sufficient, beca...Bridge users should get better feedback about which bridges are up and running, etc. This means controllers need to get an idea about the current status of the bridges as Tor sees it. Just listening to GUARD events isn't sufficient, because there will be a race between the controller attaching to Tor and Tor generating the events.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1964Tor 0.2.2.16-alpha seg faults2020-06-27T14:09:04ZRoger DingledineTor 0.2.2.16-alpha seg faultsMy bridge, running git 85cad94221aa7, just seg faulted. I failed to get a core.
Its last words, at log-level info, were
```
Sep 21 02:12:08.038 [info] update_consensus_router_descriptor_downloads(): 0 router descriptors downloadable. 2...My bridge, running git 85cad94221aa7, just seg faulted. I failed to get a core.
Its last words, at log-level info, were
```
Sep 21 02:12:08.038 [info] update_consensus_router_descriptor_downloads(): 0 router descriptors downloadable. 21 delayed; 1837 present (0 of those were in old_routers); 0 would_reject; 0 wouldnt_use; 0 in progress.
Sep 21 02:12:08.039 [info] routerlist_remove_old_routers(): We have 2910 live routers and 3326 old router descriptors.
Sep 21 02:12:21.266 [info] tor_tls_read(): Got a TLS renegotiation from "<cn>"
Sep 21 02:12:21.266 [info] command_process_versions_cell(): Negotiated version 2 with <cn>:43120; sending NETINFO.
Sep 21 02:12:22.144 [info] command_process_netinfo_cell(): Got good NETINFO cell from <cn>:43120; OR connection is now open, using protocol version 2
Sep 21 02:12:23.222 [info] connection_exit_connect_dir(): Opening local connection for anonymized directory exit
Sep 21 02:12:23.429 [info] _connection_free(): Freeing linked Directory connection [writing] with 0 bytes on inbuf, 0 on outbuf.
Sep 21 02:12:23.429 [info] connection_edge_reached_eof(): conn (fd -1) reached eof. Closing.
Sep 21 02:12:23.429 [info] _connection_free(): Freeing linked Exit connection [open] with 0 bytes on inbuf, 0 on outbuf.
Sep 21 02:12:30.080 [info] rep_hist_downrate_old_runs(): Discounting all old stability info by a factor of 0.950000
```Tor: 0.2.2.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1955Control protocol 'signal' event for when we get a hup, etc2020-06-27T14:09:05ZRoger DingledineControl protocol 'signal' event for when we get a hup, etcIt would be good to add a new 'signal' event to the control protocol, so it can tell us when we get a hup, usr1, etc. Mainly this involves adding it to control-spec.txt, and then instrumenting signal_callback() in src/or/main.c to send t...It would be good to add a new 'signal' event to the control protocol, so it can tell us when we get a hup, usr1, etc. Mainly this involves adding it to control-spec.txt, and then instrumenting signal_callback() in src/or/main.c to send the event with the right arguments.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1943Helper functions {get,set}_uint{16,32,64}() are not used2020-06-27T14:09:06ZGeorge KadianakisHelper functions {get,set}_uint{16,32,64}() are not usedThe helper functions get_uint{16,32,64}() and set_uint{16,32,64}() should be used instead of "*(uint16_t*)(cp)" etc. to avoid unaligned address access problems with specific OSes.
There are many cases in the source tree that this doesn'...The helper functions get_uint{16,32,64}() and set_uint{16,32,64}() should be used instead of "*(uint16_t*)(cp)" etc. to avoid unaligned address access problems with specific OSes.
There are many cases in the source tree that this doesn't happen.
For example, in the cell_unpack() function we have:
```
dest->command = *(uint8_t*)(src+2);
```Tor: 0.2.2.x-final