Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #20511

Closed (moved)
(moved)
Open
Created Nov 01, 2016 by Roger Dingledine@arma

add a failsafe where if you're about to serve a consensus that you know is obsolete, don't do it

http://77.247.181.162/tor/status-vote/current/consensus-microdesc is offering me a microdesc consensus document which is valid-until 2016-09-28 22:00:00. Today is Oct 31.

That relay knows what time it is -- when I establish my Tor channel to it and do a begindir fetch, it gives me good answers in the http header responses.

Yet it is happy to give me a consensus that's a month old. And my Tor client doesn't complain in any obvious useful way. I just get the cryptic line:

Oct 31 23:12:29.455 [notice] I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.

Is there a consensus age past which the correct answer for a dir cache in that situation should be "I'm really sorry, but it's for your own good: 404"?

We wouldn't want that age to be too small, or the network would fall over a lot faster in the case where it really has been 15 hours since the directory authorities made a consensus.

(Also, is 404 the right return code? It isn't that I don't have it, it's that you're not going to like it.)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking