Opened 22 months ago

Closed 22 months ago

Last modified 21 months ago

#25866 closed defect (fixed)

does DescriptorDownloader.get_server_descriptors() get non-consensus descriptors?

Reported by: cypherpunks Owned by: atagar
Priority: Medium Milestone:
Component: Archived/Stem Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

bad-relays@ runs a stem script that fetches all descriptors from the current consensus via
https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.DescriptorDownloader.get_server_descriptors

"If no fingerprints are provided then this returns all descriptors in the present consensus."

On 2018-04-20 it generated an output about relay 9925389058263BB54D4AE2319DBCD3087393EB24

I was unable to find any consensus from 2018-04-20 with this relay in it.

Only moria1 and dizum seem to vote about it.

Does .get_server_descriptors() also fetch descriptors not in consensus?

@type server-descriptor 1.0
router Lesearch2017 223.197.177.49 9090 0 9030
platform Tor 0.2.6.0-alpha-dev on Linux
protocols Link 1 2 Circuit 1
published 2018-04-20 08:26:03
fingerprint 9925 3890 5826 3BB5 4D4A E231 9DBC D308 7393 EB24
uptime 13165920
bandwidth 10485760 20971520 53832
extra-info-digest 820073CDA736DF930C03D4EA7B82FC8C43645EA7
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBANuX97BAzqakkQs1pflUljFEZwO+2yLv1TbE40sgfHnATzh5RLFw7Paf
h6y6wpWb/GYkn2BD2eLzToF/kKmaApIej0ePrIRi0XBwUBajoij+Ga+YdSQrSBOg
1WiVg+TDJM8Fkfu0UmL8ZcceztddeV+yTMRAEbdV5SAGuzY98uWDAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBANxawKDc8HTF9OEqRYQURtgdKP3OIpzufcHb4WUJUdP0IbpTwAfXguuy
xU7Xe3LmLZo9bqghoigZlbYGX8iLorIshJ0BvDNXErYv0hpqGSxrAnckwoGhgiit
Ky8oEVugV4KymqeH6gK+itMrUZm/3JvFoACrbe8f3UsxMoEMwRJ3AgMBo7M=
-----END RSA PUBLIC KEY-----
hidden-service-dir
ntor-onion-key hXVaWAq8PRgiKdIOxhRAgKZ6ECIhYsAsgsHFmxhQCEk=
reject *:*
router-signature
-----BEGIN SIGNATURE-----
Mi/lWn+p3xWllJxy3y558WuHyRNUlmtyJ4vnUvZhogQVjETNO1/t70keNDL+1JVW
Ap5BW6rfZH5ZEI0OJoif+W/8hiWvJpf/Mkn07XbNJMZbr6BsKyfcGZy/SHd6iKK9
yly/p5GVtQQO2SpgLpEXWB0Tu2cElUsOX7bCQz1LUow=
-----END SIGNATURE-----

Child Tickets

Change History (5)

comment:1 Changed 22 months ago by atagar

Resolution: fixed
Status: newclosed

Hi cypherpunks, good point. Pushed a small doc fix...

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

Unfortunately the spec is a bit vague about what server descriptors will be available but you're right that it's not necessarily what is in the consensus. Feel free to reopen with the 'Core Tor / Tor' component if you'd like more clarity about what relays will and won't be available in the response.

comment:2 Changed 21 months ago by teor

This is how Tor works in detail:
Relays try to fetch all descriptors for every consensus they successfully download and validate.
Relays cache all descriptors they have ever successfully downloaded.
Relays remove a descriptor from their cache when it expires.

So the number of descriptors returned by a relay depends on its uptime.

comment:3 Changed 21 months ago by cypherpunks

in this example the script directly connects to dir auths I guess.

comment:4 Changed 21 months ago by cypherpunks

and thanks for the fast documentation fix

comment:5 Changed 21 months ago by teor

I think recent versions of stem use fallbacks by default for descriptor fetches.

Anyway, here is the authority behaviour:
Authorities cache any descriptors posted to them by relays
Authorities try to fetch all descriptors for every vote and consensus they successfully download and validate.
Authorities cache all descriptors they have ever successfully downloaded.
Authorities remove a descriptor from their cache when it expires, or for miscordescs, when it hasn't been mentioned in a recent consensus.

So the number of descriptors returned by an authority depends on its reachability and uptime.

Note: See TracTickets for help on using tickets.