GETCONF provides incorrect value when undefined

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

changed milestone to %Tor: unspecified

added component::core tor/tor easy milestone::Tor: unspecified optional priority::medium protocol severity::minor status::new tor-control tor-spec type::defect labels

Pushed a stem workaround for now:

https://gitweb.torproject.org/stem.git/commit/?id=fc35ea1a74b6f9a95b6d1c2d21069f837dc725bb

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

Trac:
Priority: Low to Medium
Keywords: N/A deleted, easy added

Trac:
Username: icanhasaccount

patch.diff

Trac:
Username: 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?

Trac:
Username: icanhasaccount

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).

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

Trac:
Reviewer: N/A to N/A
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.???

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: easy deleted, easy optional tor-control tor-spec protocol added

moved to tpo/core/tor#18263 (closed)