[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