"PublishServerDescriptor hidserv" publishes a public relay descriptor

I ran a Tor instance with the following lines in its torrc:

ORPort 51412
BridgeRelay 1
ExitPolicy reject *:*
PublishServerDescriptor hidserv

(There were other non-comment lines in the torrc, including lines specifying hidden services, but those are not relevant.)

I expected this Tor instance to publish hidden service descriptors and not publish any router descriptor (whether bridge or public relay). Instead, it published a router descriptor as a public relay.

The hidserv parameter to the PublishServerDescriptor torrc option is obsolete, it is ignored by the code that publishes hidden service descriptors (even v0 descriptors), and the configuration-parsing code should explicitly ignore it (and print a warning).

added component::core tor/tor owner::rransom priority::high resolution::fixed status::closed tor-relay type::defect labels

See bug2408 ( !ssh://mob@repo.or.cz/srv/git/tor/rransom.git bug2408 ) for a fix.

Trac:
Status: new to needs_review

I'm too incompetent to checkout rransom's git repository. Can we set him up with a canonical Tor git?

Trac:
Points: N/A to N/A

-      *auth |= HIDSERV_AUTHORITY;
+      log_warn(LD_CONFIG,
+               "PublishServerDescriptor hidserv is obsolete. See "
+               "PublishHidServDescriptors.");

When you print your warning here, you will likely get bitten by the bug where the logs aren't set up while parsing the config. So if the user has the default stdout notice log we give him, he'll see the warning. But if this Tor is being run in some other way (started in background, launched by controller, etc) this log_warn may be silent.

I wonder what documentation we actually recommended using PublishServerDescriptor in this way.

I'm tempted to fail the Tor, rather than just warn, so the user will notice and fix it.

Replying to arma:

I'm too incompetent to checkout rransom's git repository. Can we set him up with a canonical Tor git?

That might be desirable for security reasons, but it won't make it any easier for you to pull from my repository.

Run the following commands once in each repository you want to fetch my branches into:

git remote add rransom ssh://mob@repo.or.cz/srv/git/tor/rransom.git
git fetch rransom

The server should have a 1024-bit RSA SSH key with fingerprint 07:7a:5c:6c:39:b3:ac:a9:e5:70:5d:41:ba:a6:37:04.

Then run the following commands to check out a branch from my repository:

git fetch rransom
git checkout remotes/rransom/$BRANCH_NAME

If you also want to start committing on top of my branch, run:

git checkout -b $BRANCH_NAME

Replying to arma:

{{{

•  *auth |= HIDSERV_AUTHORITY;

•  log_warn(LD_CONFIG,

•           "PublishServerDescriptor hidserv is obsolete. See "

•           "PublishHidServDescriptors.");

}}}

When you print your warning here, you will likely get bitten by the bug where the logs aren't set up while parsing the config. So if the user has the default stdout notice log we give him, he'll see the warning. But if this Tor is being run in some other way (started in background, launched by controller, etc) this log_warn may be silent.

Vidalia on Windows displays notice messages in its message log on startup, so I would expect warnings to show up there, too.

I don't know what init scripts for the various Unix-like systems do, but they can and should arrange to capture early log messages to syslog. I assume at least some of the init scripts out there don't do this.

I wonder what documentation we actually recommended using PublishServerDescriptor in this way.

The man page said that PublishServerDescriptor accepted a hidserv argument, and that PublishServerDescriptor hidserv would result in Tor only publishing descriptors to HS directories. As far as I can tell, this was never true.

I'm tempted to fail the Tor, rather than just warn, so the user will notice and fix it.

That seems reasonable, especially because if that change would halt your Tor process, this bug has already shot you in the foot, and you probably need to re-key and change your port and/or IP to keep your bridge unpublished.

I'm changing this ticket back to assigned, because this change will need to be forward-ported from maint-0.2.1 more carefully than usual (at the very least, I should forward-port the man page change, but I also want to check for other occurrences of PublishServerDescriptor in maint-0.2.2 and master just in case).

Trac:
Status: needs_review to assigned

Replying to rransom:

Vidalia on Windows displays notice messages in its message log on startup, so I would expect warnings to show up there, too.

Yes, they do, even before Vidalia has opened a control port connection to Tor. (I tested this by adding NoPublish foo to my torrc, in order to provoke a warning, and then telling Vidalia to start Tor.)

Replying to rransom:

Replying to arma:

I'm tempted to fail the Tor, rather than just warn, so the user will notice and fix it.

That seems reasonable, especially because if that change would halt your Tor process, this bug has already shot you in the foot, and you probably need to re-key and change your port and/or IP to keep your bridge unpublished.

I decided not to do this, because there are enough other configuration warnings that users really need to see those log messages, and because making Tor fail to start won't actually help get a message to the user.

I'm changing this ticket back to assigned, because this change will need to be forward-ported from maint-0.2.1 more carefully than usual (at the very least, I should forward-port the man page change, but I also want to check for other occurrences of PublishServerDescriptor in maint-0.2.2 and master just in case).

See bug2408-v2-021 for the 0.2.1 changes, and see bug2408-v2-022 for the changes for 0.2.2 and master.

Trac:
Status: assigned to needs_review
Pointsdone: N/A to N/A
Actualpoints: N/A to N/A
Actualpointsdone: N/A to N/A

Looks ok to me; merging.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

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

Trac:
Component: Tor Relay to Tor

Milestone Tor: 0.2.1.x-final deleted

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

closed

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