Re: [tor-bugs] #31611 [Core Tor/Tor]: Work out why chutney didn't fail due to #31495 cannot configure bridges

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#31611: Work out why chutney didn't fail due to #31495 cannot configure bridges
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  nickm
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  network-team-roadmap-september,      |  Actual Points:
  042-should                                     |
Parent ID:  #29211                               |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor31-must
-------------------------------------------------+-------------------------

Comment (by nickm):

 So, on investigation: bug #31495 only happened when the configuration
 change arrived over the control port via SETCONF.  If instead it arrived
 in the initial configuration, or via a SIGHUP, then #31495 would not occur
 and the configuration would not be rejected.  Chutney doesn't use SETCONF,
 so it didn't find #31495.

 But, why were the two cases handled differently?

 That's because when we build a new configuration from scratch, we
 initialize a new configuration objects, assign the defaults to it, and
 then assign each of the user-provided options in sequence.  But when we
 get new values via SETCONF, we first duplicate the existing configuration,
 and then use setconf to apply new values on top of it.  The bug here was
 in config_dup()'s handling of NULL routerset values.  Instead of encoding
 them as a null entry, we encoded them as an empty string, which was then
 re-parsed as a semantically different value.  This was due to a bug in
 routerset's var_type implementation.

 We could add a check here to make sure that config_dup() always returns an
 equal object, although that wouldn't have helped in this instance, since
 the defeault "equal" implementation for a var_type defers to the "encode"
 implementation, which is what had the bug.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31611#comment:3>
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