[tor-bugs] #22702 [Core Tor/Tor]: Never send a consensus which the downloader already has

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Jun 26 13:15:49 UTC 2017


#22702: Never send a consensus which the downloader already has
--------------------------------------------+------------------------------
 Reporter:  nickm                           |          Owner:  ahf
     Type:  defect                          |         Status:  assigned
 Priority:  High                            |      Milestone:  Tor:
                                            |  0.3.1.x-final
Component:  Core Tor/Tor                    |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  tor-relay directory regression  |  Actual Points:
Parent ID:                                  |         Points:  1
 Reviewer:                                  |        Sponsor:  Sponsor4
--------------------------------------------+------------------------------

Comment (by nickm):

 Replying to [comment:2 ahf]:
 > > Additionally, if somebody says X-Or-Diff-From the consensus which we
 currently have, then instead of telling them "That's up-to-date", we also
 send the current consensus. That's also bad.
 >
 > What is meant here by "which we currently have"? Prop#140 allows a
 client to send multiple hashes of the consensuses they have, but our
 current request sending code only ever sends one hash, but our request
 receive path handles multiple hashes (which is according to the proposal).

 If they include a hash that indicates that they would accept a diff _from_
 the most recent consensus, then they have the most recent consensus, and
 we should not send it to them.

 > Should we check if the `digest_sha3_as_signed` (from `networkstatus_t`)
 in our currently "live" consensus document, of the given client requested
 flavour, matches any one of the set of hashes the client sends to us in
 the `X-Or-Diff-From-Consensus` header - or should we only handle the case
 where a client sends one hash that happens to match the
 `digest_sha3_as_signed`? Or something entirely different?

 I think it's an "any" condition: if they say they have the most recent
 consensus, we shouldn't send them any diff.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22702#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list