Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:45:18Zhttps://gitlab.torproject.org/legacy/trac/-/issues/31647Should OBSOLETE and ___invisible configuration obtions be available to GETCONF?2020-06-13T15:45:18ZNick MathewsonShould OBSOLETE and ___invisible configuration obtions be available to GETCONF?Right now, you can use GETCONF on the invisible `___UsingTestNetworkDefaults` or the obsolete `DisableIOCP` -- without any complaint from Tor.
Perhaps Tor should complain, or even reject these requests.Right now, you can use GETCONF on the invisible `___UsingTestNetworkDefaults` or the obsolete `DisableIOCP` -- without any complaint from Tor.
Perhaps Tor should complain, or even reject these requests.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28856Discard strcmp_len()2020-06-13T15:35:43ZNick MathewsonDiscard strcmp_len()We have a strcmp_len() function that we use extensively in parsecommon. But it's just a messed-up version of strncmp. We can get better performance here if we drop it.We have a strcmp_len() function that we use extensively in parsecommon. But it's just a messed-up version of strncmp. We can get better performance here if we drop it.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28837Use openssl's SHA3 implementations when they are faster.2020-06-13T15:36:52ZNick MathewsonUse openssl's SHA3 implementations when they are faster.OpenSSL now has sha3 support. At least some versions have assembly implementations of the keccak core function. That's our signal to update crypto_digest.c to use openssl for sha3.
This matters for startup, since `keccakf()` is about ...OpenSSL now has sha3 support. At least some versions have assembly implementations of the keccak core function. That's our signal to update crypto_digest.c to use openssl for sha3.
This matters for startup, since `keccakf()` is about 10% of our startup time when we have a cached directory.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28481Tor's startup time is getting slower on Android2020-06-13T15:34:16ZTracTor's startup time is getting slower on AndroidWhen upgrading Briar's Tor binaries from 0.2.9.16 to 0.3.4.8, we noticed a difference in Tor's startup time on older Android phones.
Measuring the startup time of several recent Tor versions revealed an interesting pattern. The time tha...When upgrading Briar's Tor binaries from 0.2.9.16 to 0.3.4.8, we noticed a difference in Tor's startup time on older Android phones.
Measuring the startup time of several recent Tor versions revealed an interesting pattern. The time that elapses between starting the Tor process and the creation of the authentication cookie file hasn't changed across versions, but the time between the creation of the cookie file and the response to the AUTHENTICATE command has changed substantially. (Briar sends the AUTHENTICATE command as soon as the cookie file's created.)
I measured five runs of each version on a Motorola Moto G 4G running Android 5.1. Here are the min and max times in seconds for each version:
|= Tor version =|= Min =|= Max =|
|---------------|-------|-------|
|0.2.9.16|3.5|4.3|
|0.2.9.17|3.5|4.2|
|0.3.0.1-alpha|4.8|13.0|
|0.3.1.1-alpha|9.9|16.2|
|0.3.2.1-alpha|15.3|19.9|
|0.3.3.1-alpha|15.8|18.5|
|0.3.4.1-alpha|16.1|18.4|
|0.3.4.8|16.2|20.9|
|0.3.4.9|16.1|23.7|
The min and max have both increased substantially since 0.2.9, and the distribution has widened. This is having a noticeable impact on how long it takes for Briar to connect to contacts when the app's started.
I'll repeat these experiments on Linux x64 to see whether this is Android-specific.
**Trac**:
**Username**: akwizgranTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26647defect: Spec for net/listeners/* doesn't covers HTTPTunnelPort directive or E...2020-06-13T15:27:37ZTracdefect: Spec for net/listeners/* doesn't covers HTTPTunnelPort directive or ExtORPortThere are (rather) new type of listener, that's not covered by 'GETINFO net/listeners/*'.
**Trac**:
**Username**: pyhedgehogThere are (rather) new type of listener, that's not covered by 'GETINFO net/listeners/*'.
**Trac**:
**Username**: pyhedgehogTor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25511Expose TZ info on control port for better debugging of time errors2020-06-13T17:44:06ZNick MathewsonExpose TZ info on control port for better debugging of time errorsWhen we tell people that their clocks are wrong, it's frequently because they've set up their systems with the wrong time zone. It would be helpful to tell torbrowser (or some other controller) about this information, so that it can giv...When we tell people that their clocks are wrong, it's frequently because they've set up their systems with the wrong time zone. It would be helpful to tell torbrowser (or some other controller) about this information, so that it can give more useful error messages on time-related bootstrapping failures.
~~One complication here is (IIUC) TB runs, and runs tor, with its TZ set to UTC.~~
Further investigation suggests that TB might not set `TZ` for the first time it starts tor. Opened #25823 for the Tor Launcher behavior inconsistency.Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21329onions/detached and onions/current should return empty lists instead of errors2017-05-15T19:44:31Zmeejahonions/detached and onions/current should return empty lists instead of errorsIf you do a GETINFO query on `onions/detached` or `onions/current` and there aren't any, a 551 error is returned. Most other things just return an empty list/value in this case and I think these should too.
One consequence of this is th...If you do a GETINFO query on `onions/detached` or `onions/current` and there aren't any, a 551 error is returned. Most other things just return an empty list/value in this case and I think these should too.
One consequence of this is that if you ask for `onions/current` with some other keys and there are no current onions, the whole query will fail.
So `GETINFO onions/current` should return `onions/current=` instead of an error.
For example you can try `carml cmd getinfo orconn-status onions/current` to see this behavior.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19925SR: Control event to get the shared random values2020-06-13T15:00:18ZDavid Gouletdgoulet@torproject.orgSR: Control event to get the shared random valuesOnce all dirauth move to 029, the consensus will have a shared random value regurlarly. Having a way to get that value through the control port would be useful for many purposes including people wanting to use that value outside of tor.
...Once all dirauth move to 029, the consensus will have a shared random value regurlarly. Having a way to get that value through the control port would be useful for many purposes including people wanting to use that value outside of tor.
I recommend we implement that only in 030 so we'll have a full stable version to debug and make sure it actually works properly before we expose it to a wider audience.
This ticket is the main one for both the spec and implementation.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/18920Make consensus GETINFO return 551 when using microdescs2020-06-13T14:56:49ZteorMake consensus GETINFO return 551 when using microdescsThe tor control-spec says that 551 should be returned for "dir/status" queries where microdescs are in use, and so full descriptors are unavailable.
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n737
This doesn't happe...The tor control-spec says that 551 should be returned for "dir/status" queries where microdescs are in use, and so full descriptors are unavailable.
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n737
This doesn't happen for dir/status-vote/current/consensus when tor only has a microdesc consensus, instead, tor returns "552 Unrecognized key "dir/status-vote/current/consensus".
https://gitweb.torproject.org/tor.git/tree/src/or/control.c#n2004
The 552 is misleading and not to spec, instead, we should return 551 with a helpful error message.
Credit to s0rlxmh0 for reporting this issue.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15881Missing descriptor ID in some HS_DESC control event2020-06-13T14:45:44ZDavid Gouletdgoulet@torproject.orgMissing descriptor ID in some HS_DESC control eventThe control-spec does have it specified (see section 4.1.25) but Tor doesn't provide it for both RECEIVED and FAILED.The control-spec does have it specified (see section 4.1.25) but Tor doesn't provide it for both RECEIVED and FAILED.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14847Controller: add a command to fetch HS descriptor from HSdir(s)2020-06-13T18:28:21ZDavid Gouletdgoulet@torproject.orgController: add a command to fetch HS descriptor from HSdir(s)Last part of #3521, this is a bigger one. The ability to ask tor to fetch an HS descriptor from either the default HSdir set/replicas or onto the some specific ones given by the user.
This particular command will trigger external connec...Last part of #3521, this is a bigger one. The ability to ask tor to fetch an HS descriptor from either the default HSdir set/replicas or onto the some specific ones given by the user.
This particular command will trigger external connections to fetch those descriptors.
Furthermore, we should think about if we want the results cached by the client or not which can have bad side effects depending on the intention. Considering #3523, if tor is able to do that at some point, there could be a use for this command to fetch and store a desc. from a specific HSdir.Tor: 0.2.7.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/14845Controller: retrieve an HS descriptor from the client's cache2020-06-13T14:45:41ZDavid Gouletdgoulet@torproject.orgController: retrieve an HS descriptor from the client's cacheSplit #3521 addressing one of the three original goals from the ticket first mentionned by rransom.
The approach here is to add the key `hs/desc/id/<addr.onion>` to GETINFO command. If found, the descriptor is printed formatted as descr...Split #3521 addressing one of the three original goals from the ticket first mentionned by rransom.
The approach here is to add the key `hs/desc/id/<addr.onion>` to GETINFO command. If found, the descriptor is printed formatted as described in rend-spec.txt section 1.3.Tor: 0.2.7.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/14184Control port command "getinfo entry-guards" return all guards with the "up" s...2020-06-13T14:41:44ZDavid Gouletdgoulet@torproject.orgControl port command "getinfo entry-guards" return all guards with the "up" state`getinfo entry-guards` returns a list of guards that are all flagged as "up" even though the state file shows only one of them is actually up and all others are down.`getinfo entry-guards` returns a list of guards that are all flagged as "up" even though the state file shows only one of them is actually up and all others are down.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14128GETINFO bw-samples to give recent BW events2020-06-13T14:41:34ZNick MathewsonGETINFO bw-samples to give recent BW events#13988 raises the interval at which bandwidth measurements are sampled. That's a pain for arm, which wants to use this information to prepopulate the bandwidth graph.
atagar asks for a means to get similar information from the last 1-5...#13988 raises the interval at which bandwidth measurements are sampled. That's a pain for arm, which wants to use this information to prepopulate the bandwidth graph.
atagar asks for a means to get similar information from the last 1-5 minutes.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14127GETINFO bw-samples to give recent BW events2020-06-13T14:41:34ZNick MathewsonGETINFO bw-samples to give recent BW events#13988 raises the interval at which bandwidth measurements are sampled. That's a pain for arm, which wants to use this information to prepopulate the bandwidth graph.
atagar asks for a means to get similar information from the last 1-5...#13988 raises the interval at which bandwidth measurements are sampled. That's a pain for arm, which wants to use this information to prepopulate the bandwidth graph.
atagar asks for a means to get similar information from the last 1-5 minutes.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14126GETINFO bw-samples to give recent BW events2020-06-13T14:41:33ZNick MathewsonGETINFO bw-samples to give recent BW events#13988 raises the interval at which bandwidth measurements are sampled. That's a pain for arm, which wants to use this information to prepopulate the bandwidth graph.
atagar asks for a means to get similar information from the last 1-5...#13988 raises the interval at which bandwidth measurements are sampled. That's a pain for arm, which wants to use this information to prepopulate the bandwidth graph.
atagar asks for a means to get similar information from the last 1-5 minutes.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/11049Spec for net/listeners/* doesn't cover socket files2020-06-13T14:34:25ZDamian JohnsonSpec for net/listeners/* doesn't cover socket filesHi Nick. I'm expanding stem to take advantage of the 'GETINFO net/listener/*' options. Presently the spec simply says...
```
"net/listeners/or"
"net/listeners/dir"
"net/listeners/socks"
"net/listeners/trans"
"net/lis...Hi Nick. I'm expanding stem to take advantage of the 'GETINFO net/listener/*' options. Presently the spec simply says...
```
"net/listeners/or"
"net/listeners/dir"
"net/listeners/socks"
"net/listeners/trans"
"net/listeners/natd"
"net/listeners/dns"
"net/listeners/control"
A space-separated list of the addresses at which Tor is listening for
connections of each specified type. [New in Tor 0.2.2.26-beta.]
```
Output is usually a quoted, space separated listing of 'address:port', such as...
```
% telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
AUTHENTICATE
250 OK
GETINFO net/listeners/control
250-net/listeners/control="127.0.0.1:9051"
250 OK
```
This led me to believe that the output would always be IPv4 address and port tuples. However, turned out that for control sockets it's different...
```
% socat UNIX-CONNECT:/tmp/tor/socket STDIN
AUTHENTICATE
250 OK
GETINFO net/listeners/control
250-net/listeners/control="unix:/tmp/tor/socket"
250 OK
```
It would be nice if the spec better detailed what callers can expect to receive. Another question I have is if tor will always use '127.0.0.1' for localhost - I thought I recalled seeing '0.0.0.0' at one point but I might be misremembering.
Cheers! -DamianTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9934Add control command to drop guard nodes2020-06-13T14:32:28ZraAdd control command to drop guard nodesThe attached patches add a new control command to Tor "DUMPGUARDS" that tells the server to remove all guard nodes.The attached patches add a new control command to Tor "DUMPGUARDS" that tells the server to remove all guard nodes.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8716HashedControlPassword Doesn't Seem To Do Anything2020-06-13T14:28:44ZcypherpunksHashedControlPassword Doesn't Seem To Do AnythingAfter setting HashedControlPassword, I'm able to connect to the control port without being prompted for my password. Further, I can actually manually change the hash (for example, I can change the last few characters all to 'F'), and arm...After setting HashedControlPassword, I'm able to connect to the control port without being prompted for my password. Further, I can actually manually change the hash (for example, I can change the last few characters all to 'F'), and arm is still able to connect without prompting me. I've attached my torrc with the nickname and contact info removed.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8596Inconsistent addrmap events when resolving hostname (regression)2020-06-13T14:28:31ZTracInconsistent addrmap events when resolving hostname (regression)Tor 0.2.3.x would generate an ADDRMAP event for all addresses added to the cache, and since all resolved IPv4 addresses were added to the cache, all IPv4 addresses generated an ADDRMAP event. Ticket #7570 introduced circuit-based separat...Tor 0.2.3.x would generate an ADDRMAP event for all addresses added to the cache, and since all resolved IPv4 addresses were added to the cache, all IPv4 addresses generated an ADDRMAP event. Ticket #7570 introduced circuit-based separation of the DNS cache and "broke" that mechanism: Resolves generated via the DNSPort or a control connection do not end up in the cache and thus don't generate an ADDRMAP event. Also, when the cache is disabled by adding the `SocksPort 9050 NoCacheDNS` to the torrc, no ADDRMAP event is generated.
Git-bisect shows commit 7536c40e9641a0724f0c9e6f994306d762d37e4d[1] introduced this problem.
First, we should be clear about when to generate ADDRMAP events. From the control spec:
```
4.1.7. New Address mapping
These events are generated when a new address mapping is entered in
Tor's address map cache, or when the answer for a RESOLVE command is
found.
```
This would mean that DNS data retrieved for DNSPort queries or when NoCacheDNS is set would not trigger an event. Do we want this behavior? Or do we want to trigger ADDRMAP events for any mapping that is not already in the cache, even if it is not going to be cached anyway?
1: https://gitweb.torproject.org/tor.git/commitdiff/7536c40e9641a0724f0c9e6f994306d762d37e4d?hp=f33487668f16dbd7f95eaf8644865c28e1dd7036
**Trac**:
**Username**: DesoxyTor: 0.2.4.x-final