[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22702 [Core Tor/Tor]: Never send a consensus which the downloader already has
#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 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).
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?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22702#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs