ControlPort GETCONF does not recognize command aliases

Because commands passed to GETCONF are not looked-up in the aliases table with expand_abbrev(), we reject GETCONF requests for options that would be valid (though deprecated) if they were used in a torrc.

For example, GETCONF AllowInvalidNodes works whereas GETCONF AllowUnverifiedNodes fails. AllowUnverifiedNodes is a deprecated alias for AllowInvalidNodes.

I propose fixing this by having handle_control_getconf() first call expand_abbrev() on the option it's going to look up. I'll attach a patch that does that for review.

changed milestone to %Tor: unspecified in legacy/trac

added alias in Legacy / Trac component::core tor/tor in Legacy / Trac controller in Legacy / Trac easy in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac priority::low in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tor-client in Legacy / Trac type::defect in Legacy / Trac labels

I'm worried about doing anything that enshrines deprecated config names (especially prefix-based aliases). We'd like to be able to remove these things someday.

What's the rationale on this one? Why can't the controller use the real option names?

What's the rationale on this one? Why can't the controller use the real option names?

I'm confused by your use of "the controller"; I think I am trying to modify the controller (or/control.c:handle_control_getconf()) to perform that lookup so that it can use the real option names.

I think you must be instead asking "Why can't an application (in this case, arm) using the Tor controller pass real option names to the controller?", and some possible answers are:

• the application could have been developed before the option name it's interested in was deprecated, or
• the application would like to be able to assume that a running torrc contains real option names, so that it doesn't have to carry around option name mappings, which would just become stale, leading back to the last bullet point.

I think I must still be missing something about your comment, though -- could you elaborate?

The controller is not control.c; the controller is the program that uses the control port to control Tor.

Summarizing IRC conversation:

• Nick isn't okay with expanding abbreviations for controllers, just aliases.
• That sounds okay to cjb.
• Atagar's worried that he's going to end up emitting warnings into the Tor log each time a controller tries to refresh current settings from a torrc. (Maybe that should get a different bug.)

Yup, that's definitely a separate issue and I've never met someone that used abbreviations in their torrc so I'm not too concerned about it. Cheers! -Damian

Rate-limiting the warnings seems okay, as does emitting each one at most per torrc reload.

Separate ticket created for that issue: https://trac.torproject.org/projects/tor/ticket/1806

cjb, atagar: does that mean this trac is closable?

arma: I think the answer is "no"; they're still hoping for the aliases table (but not the general abbreviation mechanism) to get used for getconf/setconf, and I don't think it is.

Trac:
Milestone: N/A to Tor: 0.2.3.x-final

Trac:
Actualpoints: N/A to N/A
Points: N/A to N/A
Milestone: Tor: 0.2.3.x-final to Tor: unspecified

Trac:
Keywords: N/A deleted, tor-client added

Trac:
Component: Tor Client to Tor

Trac:
Keywords: tor-client deleted, tor-client controller alias easy added
Priority: Medium to Low
Reviewer: N/A to N/A
Sponsor: N/A to N/A
Severity: N/A to Normal

moved from legacy/trac#1802 (moved)

added Bug First Contribution labels and removed 1 deleted label

added Client Control API labels and removed Controller + 1 deleted label

removed milestone

closed

added Deferred label

added BugSmashFund label