Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:01:34Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20169hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND2020-06-13T15:01:34Zgrarpamphs_desc, hs_desc_content - BAD_DESC|NOT_FOUNDLooking at a handful of HS descriptors...
setevents hs_desc hs_desc_content
hsfetch 2shgsl6ca3hwqnov
3 HSDirs - BAD_DESC
3 HSDirs - NOT_FOUND
All 6 print...
650+HS_DESC_CONTENT
.
650 OKLooking at a handful of HS descriptors...
setevents hs_desc hs_desc_content
hsfetch 2shgsl6ca3hwqnov
3 HSDirs - BAD_DESC
3 HSDirs - NOT_FOUND
All 6 print...
650+HS_DESC_CONTENT
.
650 OKTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20006HSFETCH fails for hidden services which use client authentication2020-06-13T15:37:11ZsegfaultHSFETCH fails for hidden services which use client authenticationWhen using HSFETCH with a hidden service which uses client authentication, it does not return the descriptor.
Example:
```
echo "AUTHENTICATE
HSFETCH prkszpeygn2a3kxo | nc -U /var/run/tor/control
```
Output:
```
650 OK
650 HS_DESC RE...When using HSFETCH with a hidden service which uses client authentication, it does not return the descriptor.
Example:
```
echo "AUTHENTICATE
HSFETCH prkszpeygn2a3kxo | nc -U /var/run/tor/control
```
Output:
```
650 OK
650 HS_DESC REQUESTED prkszpeygn2a3kxo NO_AUTH $4D596DB0B8214621D60183B6CBF73DF67B0A97CD~CrashM jvdlgb7c3xkihcww5fypqnbkuv5dfima
650 HS_DESC FAILED prkszpeygn2a3kxo NO_AUTH $4D596DB0B8214621D60183B6CBF73DF67B0A97CD~CrashM rhdhss3jibwpmennesop3sops3mr42du REASON=BAD_DESC
650+HS_DESC_CONTENT prkszpeygn2a3kxo jvdlgb7c3xkihcww5fypqnbkuv5dfima $4D596DB0B8214621D60183B6CBF73DF67B0A97CD~CrashM
```
log:
```
Aug 27 13:29:45.000 [warn] Failed to parse introduction points. Either the service has published a corrupt descriptor or you have provided invalid authorization data.
Aug 27 13:29:45.000 [warn] Fetching v2 rendezvous descriptor failed. Retrying at another directory.
```
I took a quick look at the code and it seems like HSFETCH simply assumes no authentication is used:
{{{
rend_query = rend_data_client_create(hsaddress, desc_id, NULL,
REND_NO_AUTH);
}}}
https://gitweb.torproject.org/tor.git/tree/src/or/control.c#n4095Tor: unspecifiedrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/19859Expose stream isolation information to controllers2020-06-13T14:59:57ZNick MathewsonExpose stream isolation information to controllersSee the discussion on the "How to integrate an external name resolver into Tor" thread on tor-dev; most notably http://archives.seul.org/tor/dev/Aug-2016/msg00019.html .
Resolvers would like to know the isolation information of incoming...See the discussion on the "How to integrate an external name resolver into Tor" thread on tor-dev; most notably http://archives.seul.org/tor/dev/Aug-2016/msg00019.html .
Resolvers would like to know the isolation information of incoming streams so they know which streams need to be isolated from which other streams.
Semantically, this is a little tricky. The underlying rule that Tor implements is that each stream has a tuple of attributes (A_1, A_2... A_n), and a bit field (b_1, b_2... b_n). Two streams S_a and S_b may share the same circuit iff, for every i such that the OR of their b_i values is true, they have the same A_i value.
Note that this is not transitive: Stream S_a may be able to share a circuit with S_b or S_c, even if S_b cannot share with S_c. Worse
Should we (1) expose these attribute tuples and bitfields and require controllers to manipulate them correctly? That seems obnoxious and error-prone.
Or should we (2) allow controllers to ask questions like "may stream A share a circuit with stream B?" Or "what streams may A share a circuit with?" This might lead to O(n) queries, and it will still be error-prone because of the non-transitivity issue.
Or would it be better to (3) oversimplify the system above and provide each stream a 'cookie' such that any two streams with the same cookie may definitely share the same circuit? But this is problematic, and will overestimate how much isolation we need.
My current best idea is that (4) we should provide an operation of the form "make stream A have the same isolation properties as stream B". And possibly "make circuit C have isolation properties as if it had been used by stream A". So we don't expose isolation information, we just expose a way to manipulate it.
Or maybe there's a further clever way I'm not even thinking about just now.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19665Should *Port_set count sockets?2020-06-13T15:25:32ZteorShould *Port_set count sockets?In parse_ports in 0.2.8-stable and earlier, we didn't count sockets as listeners when setting options->*Port_set.
This makes sense for server ports, is confusing for ControlPort/ControlSocket (because you can set a control socket using ...In parse_ports in 0.2.8-stable and earlier, we didn't count sockets as listeners when setting options->*Port_set.
This makes sense for server ports, is confusing for ControlPort/ControlSocket (because you can set a control socket using the ControlPort option, can't you?), and didn't matter for client ports, because those values were never used.
In #17178 I modified the client port options to count sockets.
But we should definitely review the control port situation some time.
I don't think it's serious, because the current code warns on ControlPorts and ControlSockets.
But it makes it easy to introduce subtle bugs.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19572set Tor Control Authcookie default file location from /var/lib/tor/control.au...2020-06-13T14:59:19Zadrelanosset Tor Control Authcookie default file location from /var/lib/tor/control.authcookie to /var/run/tor/control.authcookieFor an ephermal file, the default location is much more appropriate in `/var/run/tor/control.authcookie` rather than the current default `/var/lib/tor/control.authcookie`.
To help standardize the path, please change Tor's default to `/v...For an ephermal file, the default location is much more appropriate in `/var/run/tor/control.authcookie` rather than the current default `/var/lib/tor/control.authcookie`.
To help standardize the path, please change Tor's default to `/var/run/tor/control.authcookie`, which is also what Debian is using.
-----
This would help define a more standard way across distributions how Tor control port authentication should work.
https://github.com/rustybird/corridor/issues/11
-----
https://gitweb.torproject.org/tor.git/tree/src/or/control.c?id=8917c4f19fccbe26ccea78b7fdb6d4730ef017c4#n6344
```
return get_datadir_fname("control_auth_cookie");
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19552Provide mechanism to find dirconns associated with a download_status_t, and e...2020-06-13T14:59:10ZAndrea ShepardProvide mechanism to find dirconns associated with a download_status_t, and expose active download attempts in GETINFO responseIt's hairy and complicated and different for every download status type to find out if / how many active attempts there are; we can do better.It's hairy and complicated and different for every download status type to find out if / how many active attempts there are; we can do better.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19535A can't-happen case for one-hop circuits actually can happen2020-06-13T15:29:47ZAndrea ShepardA can't-happen case for one-hop circuits actually can happenOn commit 4dc7b3ca2825741311b6b849ed109053c643ee23, using the controller EXTENDCIRCUIT command to create a new circuit like this:
`EXTENDCIRCUIT 0 0744F2AE098BAD9F1A0FEF109C01E621FB6A4600`
causes this log message:
```
Jun 30 12:50:44....On commit 4dc7b3ca2825741311b6b849ed109053c643ee23, using the controller EXTENDCIRCUIT command to create a new circuit like this:
`EXTENDCIRCUIT 0 0744F2AE098BAD9F1A0FEF109C01E621FB6A4600`
causes this log message:
```
Jun 30 12:50:44.000 [info] pathbias_should_count(): Bug: One-hop circuit has length 1. Path state is new. Circuit is a General-purpose client currently doing handshakes. (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] tor_bug_occurred_(): Bug: src/or/circpathbias.c:362: pathbias_should_count: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: Line unexpectedly reached at pathbias_should_count at src/or/circpathbias.c:362. Stack trace: (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(log_backtrace+0x2f) [0x55f6e9] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(tor_bug_occurred_+0x18e) [0x578780] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post() [0x4bcc40] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(pathbias_count_build_attempt+0x23) [0x4bcd8d] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(circuit_finish_handshake+0x1c) [0x4c2ea6] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post() [0x4dc1af] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(command_process_cell+0xa2) [0x4db6ab] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(channel_queue_cell+0x207) [0x4b1b32] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(channel_tls_handle_cell+0x2b0) [0x4b79ea] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post() [0x50c28d] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(connection_or_process_inbuf+0x141) [0x509038] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post() [0x4fd4c7] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post() [0x4fac08] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(connection_handle_read+0x1d) [0x4fad32] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post() [0x43045c] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7ffff76883dc] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post() [0x4335ed] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post() [0x433753] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(do_main_loop+0x41b) [0x43352e] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(tor_main+0xfd) [0x43772b] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post(main+0x20) [0x42efd6] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7ffff6870b45] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
Jun 30 12:50:44.000 [warn] Bug: /home/andrea/tor/test/ticket18640/tor-1182ecb3127a6e67f8ff0c5fc0d28e0a3c25ba4b-post() [0x42eee9] (on Tor 0.2.9.0-alpha-dev 1182ecb3127a6e67)
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19327controller: expose fine-grained circuit detail.2020-06-13T14:58:32ZNick Mathewsoncontroller: expose fine-grained circuit detail.circuits have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.circuits have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19326Examine fine-grained connection detail; expose via control API2020-06-13T14:58:30ZNick MathewsonExamine fine-grained connection detail; expose via control APIconnections have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.connections have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19325controller: getinfo to get status of cpuworker queues2020-06-13T14:58:30ZNick Mathewsoncontroller: getinfo to get status of cpuworker queuesTor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19324controller: events for hidden service intro point changes, descriptor changes...2020-06-13T14:58:29ZNick Mathewsoncontroller: events for hidden service intro point changes, descriptor changes, uploads, etcTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19322colntroller: add events for "I uploaded my own descriptor" or "I regenerated ...2020-06-13T14:58:29ZNick Mathewsoncolntroller: add events for "I uploaded my own descriptor" or "I regenerated my own descriptor"Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19321controller: Ensure events exist for all guard state transitions2020-06-13T14:58:28ZNick Mathewsoncontroller: Ensure events exist for all guard state transitionsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19320controller: expose and adjust timer values2020-06-13T14:58:28ZNick Mathewsoncontroller: expose and adjust timer valuesWe're increasingly making our periodic timers first-class. If we give them names, then we can monitor (or adjust them) from the controller for testing purposes.We're increasingly making our periodic timers first-class. If we give them names, then we can monitor (or adjust them) from the controller for testing purposes.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19319controller: GETINFO stats to expose OOM details2020-06-13T14:58:27ZNick Mathewsoncontroller: GETINFO stats to expose OOM detailsOur OOM handler keeps track of lots of memory-consumers. We could expose that info to the controller.Our OOM handler keeps track of lots of memory-consumers. We could expose that info to the controller.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19318controller: expose cache details.2020-06-13T14:58:27ZNick Mathewsoncontroller: expose cache details.It might be handy good to know, for each descriptor or other cached thing: where it's stored, how it's stored, what annotations on it, etc. We could have controller events for discarding things from the cache, cache compaction, etc.It might be handy good to know, for each descriptor or other cached thing: where it's stored, how it's stored, what annotations on it, etc. We could have controller events for discarding things from the cache, cache compaction, etc.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19254Provide timestamps in the CIRC_BW and STREAM_BW events2020-06-13T14:58:11ZdonnchaProvide timestamps in the CIRC_BW and STREAM_BW eventsTor emits stream and circuit bandwidth events about once per second. However delays in the control port and controller libraries makes the event time not reliable enough for accurate bandwidth measurements.
It would be useful for making...Tor emits stream and circuit bandwidth events about once per second. However delays in the control port and controller libraries makes the event time not reliable enough for accurate bandwidth measurements.
It would be useful for making bandwidth authorities if both the STREAM_BW and CIRC_BW events included timestamps in the event.Tor: 0.3.2.x-finaldonnchadonnchahttps://gitlab.torproject.org/legacy/trac/-/issues/18620HSFORGET command to clear cached client state for a HS2020-06-13T14:55:29ZTracHSFORGET command to clear cached client state for a HSThis is a patch used by the Android app [Briar](https://briarproject.org/) (since [October 2014](https://code.briarproject.org/akwizgran/briar/commit/9e5e2e2df24d84135f14adaa42111c3ea2c55df8)) that [we would like to upstream](https://cod...This is a patch used by the Android app [Briar](https://briarproject.org/) (since [October 2014](https://code.briarproject.org/akwizgran/briar/commit/9e5e2e2df24d84135f14adaa42111c3ea2c55df8)) that [we would like to upstream](https://code.briarproject.org/akwizgran/briar/issues/115). It adds an `HSFORGET` command to the control protocol which clears any cached client state relating to a specified hidden service. This can be used to flush state that's likely to be stale before trying to connect to a hidden service via an unstable network connection (such as a mobile data connection).
**Trac**:
**Username**: str4dTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18608Limiting ADD_ONION TARGET access.2020-06-13T14:55:19ZcypherpunksLimiting ADD_ONION TARGET access.Please add a torrc option that allows the user to specify the target or port range allowed for an application that creates an ephemeral hidden service.
For example, saying that it can only bind to 12.0.0.1/32 and port range [None..None]...Please add a torrc option that allows the user to specify the target or port range allowed for an application that creates an ephemeral hidden service.
For example, saying that it can only bind to 12.0.0.1/32 and port range [None..None](../compare/None...None).
The tor client should refuse creating the hidden service if the application tries values outside of that range, for example 127.0.0.1:22 or 192.168.1.1:80Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18263GETCONF provides incorrect value when undefined2020-06-13T14:54:07ZDamian JohnsonGETCONF provides incorrect value when undefinedThis is kinda subtle but CommaList and RouterList values mistakenly include a '=' when undefined...
```
GETCONF ExcludeNodes
250 ExcludeNodes=
```
By contrast here's what Bridge, a LineList value, provides...
```
GETCONF Bridge
250 Br...This is kinda subtle but CommaList and RouterList values mistakenly include a '=' when undefined...
```
GETCONF ExcludeNodes
250 ExcludeNodes=
```
By contrast here's what Bridge, a LineList value, provides...
```
GETCONF Bridge
250 Bridge
```Tor: unspecified