[tor-bugs] #27849 [Core Tor/Tor]: incompatibility between tor 0.3.4.8 and onion.debian.org torrc (SocksPort 0)

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Sep 25 12:35:21 UTC 2018


#27849: incompatibility between tor 0.3.4.8 and onion.debian.org torrc (SocksPort
0)
----------------------------------------------+----------------------------
 Reporter:  pabs                              |          Owner:  (none)
     Type:  defect                            |         Status:  new
 Priority:  Very High                         |      Milestone:  Tor:
                                              |  0.3.5.x-final
Component:  Core Tor/Tor                      |        Version:  Tor:
                                              |  0.3.4.8
 Severity:  Normal                            |     Resolution:
 Keywords:  config, regression, backport-034  |  Actual Points:
Parent ID:                                    |         Points:
 Reviewer:                                    |        Sponsor:
----------------------------------------------+----------------------------
Changes (by dgoulet):

 * priority:  Medium => Very High


Comment:

 Wow that is a pretty epic bug that went totally unnoticed in 034...

 This is related to our mainloop refactoring where we created "Roles" and
 only enable callbacks if you are configured for that "Role". For example,
 if you are configured to be a hidden service, we'll enable the
 `hs_service` callback or if you are a relay we enable `rotate_onion_key`.
 See `periodic_events` in mainloop.c

 Now, here lies the issue. With this configuration that is nothing except
 `ControlPort`, tor has basically no roles (see `get_my_roles()`). So, the
 `rescan_periodic_events()` doesn't enable anything because it thinks your
 tor just is pointless there.

 But that isn't true since `ControlPort` is defined thus some external
 party can interact with tor and thus it should be working properly.

 I believe the issue lies with the "client" detection role where we use the
 following but that function ignores the control port entirely (and extra
 points, this is my fault: 67a41b63063370c2 - #26062).

 {{{
   int is_client = options_any_client_port_set(options);
 }}}

 Apart from the mainloop issue, I don't think not having the control port
 considered in that function is the problem. Instead, what we should do is
 enable our periodic events for the "ALL" role if the control port is
 opened as in "tor will do the basics".

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27849#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list