Opened 4 years ago

Last modified 2 years ago

#18263 new defect

GETCONF provides incorrect value when undefined

Reported by: atagar Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Minor Keywords: easy optional tor-control tor-spec protocol
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This is kinda subtle but CommaList and RouterList values mistakenly include a '=' when undefined...

GETCONF ExcludeNodes
250 ExcludeNodes=

By contrast here's what Bridge, a LineList value, provides...

GETCONF Bridge
250 Bridge

Child Tickets

Attachments (1)

patch.diff (799 bytes) - added by icanhasaccount 3 years ago.

Download all attachments as: .zip

Change History (11)

comment:2 Changed 4 years ago by arma

Milestone: Tor: 0.2.8.x-final

comment:3 Changed 3 years ago by arma

Keywords: easy added
Priority: LowMedium

Changed 3 years ago by icanhasaccount

Attachment: patch.diff added

comment:4 Changed 3 years ago by icanhasaccount

It looks like the empty values are created in confparse.c:

case CONFIG_TYPE_CSV:

if (*(smartlist_t)value)

result->value =

smartlist_join_strings(*(smartlist_t)value, ",", 0, NULL);

else

result->value = tor_strdup("");

break;

...

case CONFIG_TYPE_ROUTERSET:

result->value = routerset_to_string(*(routerset_t)value);
break;

...

The attached patch attempts to fix the output in handle_control_getconf - but I'm not sure its the best approach?

comment:5 Changed 3 years ago by cypherpunks

Tor control protocol spec is awfully vague about this.

Section 3.3 says:

  Request the value of a configuration variable.  The syntax is:

    "GETCONF" 1*(SP keyword) CRLF

  If all of the listed keywords exist in the Tor configuration, Tor replies
  with a series of reply lines of the form:
      250 keyword=value
  If any option is set to a 'default' value semantically different from an
  empty string, Tor may reply with a reply line of the form:
      250 keyword

"Tor may" or may not. According to this, the problem is/was on your side, atagar.

Also, even if this was instead a MUST, the implication would say:
( "option set to default value" AND "that value is semantically different from an empty string" ) THEN "reply line omits '=value'"

Which, aside from leaving one wondering what "semantically different from an empty string" precisely means, still allows for an "=" followed by an empty value (f.i. if said empty value is not the default).

comment:6 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

Worth fixing; doesn't have to be 0.2.8 since not a regression.

comment:7 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:8 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:9 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:10 Changed 2 years ago by nickm

Keywords: optional tor-control tor-spec protocol added
Note: See TracTickets for help on using tickets.