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):

 Moving forward, here are the possible solutions I can see:

 1. When we fuzz configurations, we test that if a configuration passes
 validation, it still passes validation when it is duplicated.

 2. (a) We can document more carefully the dangers of configuration values
 where NULL and "" mean different things.  (In the case of EntryNodes, NULL
 means "all nodes are included", and "" means "no nodes are included".)

 2. (b) We avoid configuration types where NULL and "" mean different
 things.  We would have to add a new routerset type meaning "all routers",
 (maybe, "*"?) and have that be the default for EntryNodes.  [We probably
 could not make NULL mean the same as "" for all cases, since there are
 lots of string-valued configuration types.]

 3. We write a testing tool that uses stem to try assigning configurations
 and making sure that they pass and fail with the expected errors messages.

 4. We change the implementation of SETCONF so that instead of starting
 with config_dup(), it remembers the actual sequence of configuration
 values, appends the controller's new configuration values, and replays all
 of them in sequence. [This solution would require arbitrary amounts of
 memory.]

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