Opened 5 years ago

Closed 2 years ago

#12559 closed enhancement (wontfix)

DirPort can't fetch router status entries by fingerprint

Reported by: atagar Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor's DirPort provides server and extrainfo descriptors by fingerprint, this is great!

http://<hostname>/tor/server/fp/...
http://<hostname>/tor/extra/fp/...

However, it lacks a counterpart for router status entries. Callers can retrieve the whole consensus...

http://<hostname>/tor/status-vote/current/consensus

... but not individual relays.

Tor doesn't need this, but it would be really handy for callers of stem's remote descriptor module. I just noticed this was missing because I wanted to improve the control interpreter to not rely on local descriptors for its /info lookups (since that's frequently stale, causing confusion) but realized I couldn't without pulling the full consensus. :(

Child Tickets

Change History (5)

comment:1 Changed 5 years ago by nickm

Milestone: Tor: unspecified

I'm not too thrilled about serving these unsigned. Is this something it would make more sense to do via the controller interface?

comment:2 Changed 5 years ago by atagar

I don't see how that's related to this...

  • Whole advantage of the DirPort is that you don't need a local tor instance just to fetch descriptor data.
  • The point of this ticket is that it's unfortunate that you need to download the whole consensus to get information about a single relay. Going though the control port would mean downloading the whole consensus.

If this is something that really concerns you then maybe the authority or directory mirror we're fetching from should simply append a signature for the router status entry?

comment:3 Changed 3 years ago by arma

Severity: Normal

I agree with Nick that serving unsignd subsets of the consensus via the dirport is a sketchy idea.

Something that's using the dirport for this feature could very easily end up using it unsafely.

I would suggest that the better behavior for a program that wants to use the dirport for this feature is to fetch the consensus and cache it locally, and then when it wants to do a lookup, do an if-modified-since dirport request for the consensus, and get and verify the signature and cache a new version if there is one, and then use the chunk of the consensus that it wanted to use.

Or is this external application going to want to do just one routerstatus lookup?

comment:4 Changed 3 years ago by teor

I wonder if OnionOO is a better data source than the consensus or routerstatus for this use case.

comment:5 Changed 2 years ago by nickm

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.