Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:25:37Zhttps://gitlab.torproject.org/legacy/trac/-/issues/26082control: ANY_EVENT_IS_INTERESTING() needs to mask the event before testing2020-06-13T15:25:37ZDavid Gouletdgoulet@torproject.orgcontrol: ANY_EVENT_IS_INTERESTING() needs to mask the event before testingWe merged very recently `0c19ce7bdece5906e035e71d3fb682632c8bb9cb` which introduced a problem that made all the control events to not work.
In a nutshell, the macro `ANY_EVENT_IS_INTERESTING()` is doing it wrong. The event passed to the...We merged very recently `0c19ce7bdece5906e035e71d3fb682632c8bb9cb` which introduced a problem that made all the control events to not work.
In a nutshell, the macro `ANY_EVENT_IS_INTERESTING()` is doing it wrong. The event passed to the macro should be masked before tested using `EVENT_MASK_`. And we shouldn't use `EVENT_IS_INTERESTING()` which only apply to a single event.
Fortunately, tor wasn't released so we can just fix it.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/25842'GETINFO exit-policy/full' fails when disconnected2020-06-13T15:24:31ZDamian Johnson'GETINFO exit-policy/full' fails when disconnectedOn #25423 dmr noticed that 'GETINFO exit-policy/full' fails when tor lacks an address...
```
ProtocolError: GETINFO response didn't have an OK status:
router_get_my_routerinfo returned NULL
```
No big whoop, but for this method to be u...On #25423 dmr noticed that 'GETINFO exit-policy/full' fails when tor lacks an address...
```
ProtocolError: GETINFO response didn't have an OK status:
router_get_my_routerinfo returned NULL
```
No big whoop, but for this method to be useful I need for it to always tell us what our effective policy is (maybe that's 'reject *:*' when disconnected?). In the meantime Stem is using the following as a workaround...
https://gitweb.torproject.org/stem.git/commit/?id=f61e913Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25630Bug: 3-hop circuit 0x55e55d447270 with purpose 5 has no guard state2020-06-13T15:23:41ZmeejahBug: 3-hop circuit 0x55e55d447270 with purpose 5 has no guard stateAfter discussion on #tor-dev, arma told me to file this; I am hitting this for every circuit my exit-scanner creates when using tor master (0eed0899cdeadd84).
The circuits created all start with a current guard (but probably not any of ...After discussion on #tor-dev, arma told me to file this; I am hitting this for every circuit my exit-scanner creates when using tor master (0eed0899cdeadd84).
The circuits created all start with a current guard (but probably not any of "my" current guards). I've tried with both purpose=general and purpose=controller but the result is the same (except for the 5 vs 21 in the error message)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25617unable to resolve DNS requests from control port, regression2020-06-13T15:23:39Zstarlightunable to resolve DNS requests from control port, regression```
setevents addrmap
250 OK
resolve blog.torproject.org
250 OK
650 ADDRMAP blog.torproject.org <error> "2018-03-25 08:39:54" error=yes EXPIRES="2018-03-25 12:39:54" CACHED="NO"
```
```
Mar 25 08:39:55 Tor[]: Refusing to connect to hos...```
setevents addrmap
250 OK
resolve blog.torproject.org
250 OK
650 ADDRMAP blog.torproject.org <error> "2018-03-25 08:39:54" error=yes EXPIRES="2018-03-25 12:39:54" CACHED="NO"
```
```
Mar 25 08:39:55 Tor[]: Refusing to connect to hostname [scrubbed] because Port has NoDNSRequest set.
```Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20699prop224: Add control port events and commands2020-06-13T15:22:45ZDavid Gouletdgoulet@torproject.orgprop224: Add control port events and commandsThis is quite massive work as we'll have to either modify the current events/commands to support proposal 224 or create a brand new set. There are probably new command that we would like to support. For instance, client authorization.
T...This is quite massive work as we'll have to either modify the current events/commands to support proposal 224 or create a brand new set. There are probably new command that we would like to support. For instance, client authorization.
This should be it's own proposal and then merged in control-spec.txt.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23271control_auth_cookie isn't deleted when tor stops2020-06-13T15:19:18Zyurivict271control_auth_cookie isn't deleted when tor stopsWhen tor is stopped gracefully ('service stop tor' on FreeBSD), it leaves the file /var/db/tor/control_auth_cookie.
Due to the sensitive nature of this file, it should be only present when tor runs and deleted once it stops gracefully.When tor is stopped gracefully ('service stop tor' on FreeBSD), it leaves the file /var/db/tor/control_auth_cookie.
Due to the sensitive nature of this file, it should be only present when tor runs and deleted once it stops gracefully.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24543Coverity CID 1425733: Calling "hs_parse_address" without checking return value2020-06-13T15:18:28ZAlexander Færøyahf@torproject.orgCoverity CID 1425733: Calling "hs_parse_address" without checking return valueIn /src/or/hs_control.c: 225 in `hs_control_hspost_command()` we call `hs_parse_address()` without checking the return address.In /src/or/hs_control.c: 225 in `hs_control_hspost_command()` we call `hs_parse_address()` without checking the return address.Tor: 0.3.3.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24230control: HS_DESC event failed upload sends back the wrong Action2020-06-13T15:17:13ZDavid Gouletdgoulet@torproject.orgcontrol: HS_DESC event failed upload sends back the wrong ActionWhen a descriptor upload fails, tor sends on the control port a `UPLOAD_FAILED` event where in fact it should be sending a `FAILED` event as the action with the reason: `UPLOAD_REJECTED` or `UNEXPECTED`.
The `control_event_hs_descriptor...When a descriptor upload fails, tor sends on the control port a `UPLOAD_FAILED` event where in fact it should be sending a `FAILED` event as the action with the reason: `UPLOAD_REJECTED` or `UNEXPECTED`.
The `control_event_hs_descriptor_upload_failed()` is the offending function.
The control spec does not specify at all the `Action=UPLOAD_FAILED` nor Stem for instance knows about it so this is a problem on tor side.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24128GETCONF doesn't resolve "auto" settings2020-06-13T15:16:54ZTaylor YuGETCONF doesn't resolve "auto" settingsRight now tor doesn't resolve `auto` settings when reporting them via `GETCONF`. This means the controller might need to know beforehand how tor will behave for any given `auto` setting, which might change across tor versions or even ac...Right now tor doesn't resolve `auto` settings when reporting them via `GETCONF`. This means the controller might need to know beforehand how tor will behave for any given `auto` setting, which might change across tor versions or even across consensuses. We should have a way to resolve `auto` settings so controllers can discover what setting tor will actually use.
Implementing this could be a lot of work because I think the behavior of many `auto` values gets determined by code in the relevant subsystem rather than in a centralized place like control.c.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24110document control protocol router status format surprises when using microdesc...2020-06-13T15:16:48Zteordocument control protocol router status format surprises when using microdescriptorsIn Tor 0.3.0 (or earlier?), we made clients use microdescriptors by default. This changes the format of NS_CONTROL_PORT routerstatus lines, which breaks pytorctl, and therefore the bandwidth authorities.
Apparently, this issue can be re...In Tor 0.3.0 (or earlier?), we made clients use microdescriptors by default. This changes the format of NS_CONTROL_PORT routerstatus lines, which breaks pytorctl, and therefore the bandwidth authorities.
Apparently, this issue can be resolved by setting UseMicrodescriptors 0 or using 0.2.9.
edit: Let's update control-spec.txt to document the current (surprising) behavior and track further behavior improvements in other tickets.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23977control-spec.txt should document which "signals" don't actually exist as Unix...2020-06-13T15:16:13ZTaylor Yucontrol-spec.txt should document which "signals" don't actually exist as Unix signalsSection 3.7 of control-spec.txt documents the `SIGNAL` command, which can cause some actions that correspond to Unix signals that one can send to the tor process. Some of these actions have no corresponding Unix signals, so can only be ...Section 3.7 of control-spec.txt documents the `SIGNAL` command, which can cause some actions that correspond to Unix signals that one can send to the tor process. Some of these actions have no corresponding Unix signals, so can only be invoked via the control protocol. We should document these facts to avoid confusion.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23924Improve control-spec.txt2020-06-13T15:16:06ZTom Rittertom@ritter.vgImprove control-spec.txtI was reading through control-spec.txt and made some commits I think would improve it: https://github.com/tomrittervg/torspec/commits/control-spec-editorial-1
(Do we have a torspec component? Couldn't find it if so...)I was reading through control-spec.txt and made some commits I think would improve it: https://github.com/tomrittervg/torspec/commits/control-spec-editorial-1
(Do we have a torspec component? Couldn't find it if so...)Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23613some control protocol GETINFO downloads/networkstatus keys are lies2020-06-13T15:14:29ZTaylor Yusome control protocol GETINFO downloads/networkstatus keys are liesSome of the `GETINFO downloads/networkstatus/*` keys are misleadingly named, and some can't possibly produce what they claim to do given the internal state of tor.
During bootstrap, only one flavor of consensus gets downloaded, but ther...Some of the `GETINFO downloads/networkstatus/*` keys are misleadingly named, and some can't possibly produce what they claim to do given the internal state of tor.
During bootstrap, only one flavor of consensus gets downloaded, but there are separate download schedules for mirror vs authority. After bootstrap, there are separate download schedules for each flavor of consensus. Currently, the control protocol returns authority and mirror bootstrap schedules when asked for ns and microdesc bootstrap schedules, respectively.
We should accept `downloads/networkstatus/mirror/bootstrap` and `downloads/networkstatus/authority/bootstrap` keywords and return the appropriate schedules.
`downloads/networkstatus/ns/bootstrap` and `downloads/networkstatus/microdesc/bootstrap` should only return valid results for the flavor we're using to bootstrap. There is the question of whether to return the mirror or authority schedule.
If the controller doesn't specify bootstrap vs running, should we use the "running" schedule during bootstrap if we're asked for a flavor that we're not using to bootstrap?
We should return an error code like `552` (unrecognized entity -- or is a different code better here?) if the requested information isn't available.
Thanks to teor for feedback.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23237Add 'GETINFO ip-to-country/available'2020-06-13T15:12:43ZDamian JohnsonAdd 'GETINFO ip-to-country/available'Hi Nick. Very minor ask but if we had a 'GETINFO ip-to-country/available' option to determine if tor has a geoip database available that would simplify Stem a bit. Stem tracks 'is the geoip database available' so it can avoid 'GETINFO ip...Hi Nick. Very minor ask but if we had a 'GETINFO ip-to-country/available' option to determine if tor has a geoip database available that would simplify Stem a bit. Stem tracks 'is the geoip database available' so it can avoid 'GETINFO ip-to-country/*' requests that are doomed to fail anyway.
Thanks!Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22684Expose we_fetch_{micro,router_}descriptors on control port2020-06-13T15:10:24ZNick MathewsonExpose we_fetch_{micro,router_}descriptors on control portRight now, stem has some slightly wrong logic:
https://gitweb.torproject.org/stem.git/tree/stem/control.py#n1828
We should make GETINFO commands to fetch these. How about
```
info/config/we-download-microdescs and
info/config/we-down...Right now, stem has some slightly wrong logic:
https://gitweb.torproject.org/stem.git/tree/stem/control.py#n1828
We should make GETINFO commands to fetch these. How about
```
info/config/we-download-microdescs and
info/config/we-download-routerdescs
```
?Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22644Assert crash with HSPOST and POSTDESCRIPTOR control port commands2020-06-13T15:10:17ZdonnchaAssert crash with HSPOST and POSTDESCRIPTOR control port commandsThe HSPOST and POSTDESCRIPTOR control port command accept multi-line data. Both of these commands crash when they receive an empty command body.
A trivial test case is as follows:
```
AUTHENTICATE
+HSPOST
.
```
Stacktraces:
```
Jun 18...The HSPOST and POSTDESCRIPTOR control port command accept multi-line data. Both of these commands crash when they receive an empty command body.
A trivial test case is as follows:
```
AUTHENTICATE
+HSPOST
.
```
Stacktraces:
```
Jun 18 19:27:41.000 [err] tor_assertion_failed_(): Bug: ../src/or/control.c:3098: handle_control_postdescriptor: Assertion cp failed; aborting. (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: Assertion cp failed in handle_control_postdescriptor at ../src/or/control.c:3098. Stack trace: (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(log_backtrace+0x42) [0x564171496242] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(tor_assertion_failed_+0x94) [0x5641714a44f4] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(connection_control_process_inbuf+0x279a) [0x5641714602da] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(+0xe81c5) [0x56417144a1c5] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(+0x410f1) [0x5641713a30f1] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fe33b428420] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(do_main_loop+0x21d) [0x5641713a40bd] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(tor_main+0x1b95) [0x5641713a7675] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(main+0x19) [0x56417139fdc9] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fe33a5643f1] (on Tor 0.2.8.9 )
Jun 18 19:27:41.000 [err] Bug: tor(+0x3de1b) [0x56417139fe1b] (on Tor 0.2.8.9 )
[1] 14542 abort tor -f torrc.local
```
```
Jun 18 19:35:43.000 [err] tor_assertion_failed_(): Bug: ../src/common/util.c:316: tor_strndup_: Assertion n < SIZE_T_CEILING failed; aborting. (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: Assertion n < SIZE_T_CEILING failed in tor_strndup_ at ../src/common/util.c:316. Stack trace: (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(log_backtrace+0x42) [0x564aa98a8242] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(tor_assertion_failed_+0x94) [0x564aa98b64f4] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(tor_strndup_+0x91) [0x564aa98b6e01] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(+0x3bef8) [0x564aa97afef8] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(connection_control_process_inbuf+0x1e1f) [0x564aa987195f] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(+0xe81c5) [0x564aa985c1c5] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(+0x410f1) [0x564aa97b50f1] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f1ea6c60420] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(do_main_loop+0x21d) [0x564aa97b60bd] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(tor_main+0x1b95) [0x564aa97b9675] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(main+0x19) [0x564aa97b1dc9] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f1ea5d9c3f1] (on Tor 0.2.8.9 )
Jun 18 19:35:43.000 [err] Bug: tor(+0x3de1b) [0x564aa97b1e1b] (on Tor 0.2.8.9 )
[1] 15378 abort tor -f torrc.local
```Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21974Race: Tor declares controlport listener open before it has written its contro...2020-06-13T15:07:57ZRoger DingledineRace: Tor declares controlport listener open before it has written its controlcookie to diskWhen I start my Tor client, I see this in its logs:
```
Apr 17 00:49:35.238 [notice] Opening Control listener on 127.0.0.1:9051
```
In fact, controllers like txtorcon and nyx might imagine that they can use this log line as an indicatio...When I start my Tor client, I see this in its logs:
```
Apr 17 00:49:35.238 [notice] Opening Control listener on 127.0.0.1:9051
```
In fact, controllers like txtorcon and nyx might imagine that they can use this log line as an indication that the control port is up and usable:
https://github.com/meejah/txtorcon/blob/master/txtorcon/controller.py#L131
But looking through Tor's code, that log line comes from connection_listener_new() which comes from retry_listener_ports() which comes from retry_all_listeners() which comes from options_act_reversible(), which gets called before options_act(), which is where we call init_control_cookie_authentication().
So:
A) Is there a recommendation we can make to controllers about how they can know when our control port is ready? I guess the answer right now is "when the control port is open and also when the control cookie file is there"? Is that accurate? Should we worry about races writing/reading the cookie file?
B) Should we rearrange the order of stuff in options_act*() so things are in place for the control port when we do the log message indicating that it's open?
C) We sure have a bunch of stuff we do at startup now, and the dependency graph of what has to happen before what is complicated, and I bet there are bugs in the current order of things. I've opened #21975 for this bigger refactor idea.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21813create a JSON-based alternative control port protocol2020-06-13T15:07:27ZArthur Edelsteincreate a JSON-based alternative control port protocolThe control port protocol is rather complex and it's difficult to get the syntax exactly right. So I think it would be very nice if we had an optional JSON-based protocol as well. The commands, responses and events could essentially have...The control port protocol is rather complex and it's difficult to get the syntax exactly right. So I think it would be very nice if we had an optional JSON-based protocol as well. The commands, responses and events could essentially have the same content. Writing a control port client would be greatly accelerated and much easier to ensure correctness, thereby making adoption of Tor easier for applications and tor controllers or monitoring apps. As an example, I would gladly drop the tor-control-port.js module in torbutton in favor of a JSON-based client.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20469Expose predicted-ports state over the control port2020-06-13T15:02:22ZRoger DingledineExpose predicted-ports state over the control portWhile debugging #19969 I wanted to ask my Tor whether it had any predicted ports in its internal state. But I think there is no way to ask it? I would like a 'getinfo predicted-ports' or the like.While debugging #19969 I wanted to ask my Tor whether it had any predicted ports in its internal state. But I think there is no way to ask it? I would like a 'getinfo predicted-ports' or the like.Tor: unspecified