Opened 3 years ago

Last modified 2 years ago

#24617 new enhancement

Feature flags for new controller-accessible Tor features

Reported by: meejah Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, 035-removed-20180711
Cc: 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.

Child Tickets

Change History (7)

comment:1 Changed 3 years ago by meejah

Summary: Feature flags for new Tor featuresFeature flags for new controller-accessible Tor features

comment:2 Changed 3 years ago by meejah

nickm points out on #tor-dev that Proposition 264 ("Putting version numbers on the Tor subprotocols") might be a good basis for this.

comment:3 Changed 3 years ago by teor

Keywords: needs-proposal added
Milestone: Tor: 0.3.5.x-final

comment:4 Changed 3 years ago by meejah

One concrete use-case is "unix sockets". Instead of relying on some heuristics about the operating system and particular Tor version, simply asking Tor "are you willing to use unix-sockets for anything?" (e.g. onion services) would be nice.

This seems better than trying to add an onion-service on a unix-socket, finding out it fails and then falling back to TCP.

comment:5 Changed 2 years ago by meejah

Another compelling use-case is "v3 onion authentication". Currently, txtorcon just hard-codes this as "no auth on v3 onions".

However, as this feature gets developed it would be nice to have support "early" in txtorcon but there's not a great way to tell if the tor we connected to actually supports this yet. If txtorcon can query a GETINFO or similar (e.g. GETINFO feature/onion-v3-auth or similar) I could add support "now" and the controller code can make informed decisions about whether to even try setting up authentication.

(Currently, the only option would be to try and see if it fails. However, with some of this stuff the "failure mode" is that Tor exits because the config is invalid -- e.g. if you're connected to an older Tor and *aren't* using ADD_ONION, a SETCONF with invalid config can nuke the whole Tor process).

comment:6 in reply to:  5 Changed 2 years ago by teor

Replying to meejah:

Another compelling use-case is "v3 onion authentication". Currently, txtorcon just hard-codes this as "no auth on v3 onions".

The way our workflow works, if you ask for a feature flag on the feature ticket, it's much more likely to happen.
In this case, it's #20700, and I'll ask for you.

comment:7 Changed 2 years ago by nickm

Keywords: 035-removed-20180711 added
Milestone: Tor: 0.3.5.x-finalTor: unspecified

These tickets are being triaged out of 0.3.5. The ones marked "035-roadmap-proposed" may return.

Note: See TracTickets for help on using tickets.