Opened 8 years ago

Last modified 3 years ago

#6505 needs_revision defect

GETINFO dir/status-vote/current/consensus returns "Unrecognized key" if no consensus available

Reported by: zwol Owned by: zwol
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor:
Severity: Minor Keywords: tor-client tor-control needs-spec easy
Cc: atagar, brade, mcs Actual Points:
Parent ID: Points: .2
Reviewer: Sponsor:


If there is no consensus available, issuing a GETINFO command for dir/status-vote/current/consensus will return an "Unrecognized key" error instead of an empty string, which will make pytorctl crash.

Patch attached.

Child Tickets

Attachments (1)

patch-6505 (536 bytes) - added by zwol 8 years ago.

Download all attachments as: .zip

Change History (10)

Changed 8 years ago by zwol

Attachment: patch-6505 added


comment:1 Changed 8 years ago by arma

Cc: atagar added
Milestone: Tor: 0.2.3.x-final
Status: newneeds_review

Certainly "unrecognized key" is the wrong answer.

Perhaps something that explains that the consensus is missing is better than just pretending we have a consensus and it's zero length?

Sounds like pytorctl might want to tolerate this situation better too.

comment:2 Changed 8 years ago by nickm

Status: needs_reviewneeds_revision

Agreed with arma: the consensus is never an empty string, so returning an empty string is never right. Setting a different error would make more sense.

If pytorctl crashes when it asks for a consensus and we don't have one yet, pytorctl is broken.

comment:3 Changed 8 years ago by zwol

I had actually gotten the impression that an empty string was what one got, in general, from GETINFO commands where the key was recognized but no value was available. This was from reading the controller spec in a hurry very late at night, so I could easily be wrong.

Agreed that pytorctl should handle the situation better.

comment:4 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

Hm. If we're going to add a new error code here though (say, "452 data not available"), we probably want to use it for other cases that currently yield "552 unrecognized key" too. And doing that might well break other controllers.

I think for 0.2.3 the right answer is that we should fix pytorctl. For 0.2.4, we can figure out which kind of change would be least disruptive to the other controllers.

comment:5 Changed 8 years ago by nickm

Keywords: tor-client added

comment:6 Changed 8 years ago by nickm

Component: Tor ClientTor

comment:7 Changed 8 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: unspecified

comment:8 Changed 6 years ago by mcs

Cc: brade mcs added

comment:9 Changed 3 years ago by nickm

Keywords: tor-control needs-spec easy added
Points: .2
Priority: MediumLow
Severity: Minor
Note: See TracTickets for help on using tickets.