[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs