Opened 20 months ago

Last modified 14 months ago

#23613 new defect

some control protocol GETINFO downloads/networkstatus keys are lies

Reported by: catalyst Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: bootstrap, tor-control, tor-spec, 033-triage-20180320, 033-removed-20180320
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Some of the GETINFO downloads/networkstatus/* keys are misleadingly named, and some can't possibly produce what they claim to do given the internal state of tor.

During bootstrap, only one flavor of consensus gets downloaded, but there are separate download schedules for mirror vs authority. After bootstrap, there are separate download schedules for each flavor of consensus. Currently, the control protocol returns authority and mirror bootstrap schedules when asked for ns and microdesc bootstrap schedules, respectively.

We should accept downloads/networkstatus/mirror/bootstrap and downloads/networkstatus/authority/bootstrap keywords and return the appropriate schedules.

downloads/networkstatus/ns/bootstrap and downloads/networkstatus/microdesc/bootstrap should only return valid results for the flavor we're using to bootstrap. There is the question of whether to return the mirror or authority schedule.

If the controller doesn't specify bootstrap vs running, should we use the "running" schedule during bootstrap if we're asked for a flavor that we're not using to bootstrap?

We should return an error code like 552 (unrecognized entity -- or is a different code better here?) if the requested information isn't available.

Thanks to teor for feedback.

Child Tickets

Change History (3)

comment:1 Changed 14 months ago by nickm

Keywords: 033-triage-20180320 added

Marking all tickets reached by current round of 033 triage.

comment:2 Changed 14 months ago by nickm

Keywords: 033-removed-20180320 added

Mark all not-already-included tickets as pending review for removal from 0.3.3 milestone.

comment:3 Changed 14 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: unspecified

These tickets were marked as removed, and nobody has said that they can fix them. Let's remember to look at 033-removed-20180320 as we re-evaluate our triage process, to see whether we're triaging out unnecessarily, and to evaluate whether we're deferring anything unnecessarily. But for now, we can't do these: we need to fix the 033-must stuff now.

Note: See TracTickets for help on using tickets.