[tor-bugs] #24617 [Core Tor/Tor]: Feature flags for new Tor features

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Dec 13 18:54:43 UTC 2017


#24617: Feature flags for new Tor features
------------------------------+--------------------
     Reporter:  meejah        |      Owner:  (none)
         Type:  enhancement   |     Status:  new
     Priority:  Medium        |  Milestone:
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:                |
------------------------------+--------------------
 As Tor grows new features available via the control protocol, it would be
 useful to indicate support for these features via some GETINFO.

 Currently, controllers have two ways to discover if the Tor they connected
 to supports a feature: "just try" and see if there's an error; or look at
 the Tor version.

 Both of these can be problematic:

 You can't always "just try". For example, when HS_DESC was first added as
 an event it didn't include the onion address, so you'd wait forever to see
 if a descriptor was uploaded. For completely new commands, "just try" is
 probably sufficient but when commands gain new capabilities and/or options
 it can get less obvious what the right thing to do is.

 Doing version comparisons can get tricky: as a new feature is implemented,
 it will generally appear on master first, then maybe in an alpha release
 and finally in a "real/full" release. A controller wanting to take fullest
 advantage of a new feature (e.g. to let users test it against a Tor from
 "master") would have to program in each of these versions separately,
 which is tedious.

 Instead, a definitive "GETINFO" which returns details of the feature would
 be ideal. Then, a controller can change its behavior and take advantage of
 a new feature as soon as it's on master and users can continue to take
 advantage of this as the feature moves through alphas, betas, etcetera.
 This would also work well for features that can be turned off (or on)
 through other mechanisms (e.g. configuration, command-line or build
 options).

 Such flags could also "roll up" logical features that actually need
 multiple controller commands/events to work. For example, adding v3
 services changed some config options, modified the ADD_ONION command and
 (later) provided upload information via the HS_DESC event. So until the
 ADD_ONION *and* HS_DESC changes landed, a controller couldn't properly add
 a v3 ephemeral service.

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


More information about the tor-bugs mailing list