[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #33029 [Core Tor/Tor]: dir-auth: Never send a 503 directory request code to another directory authority

#33029: dir-auth: Never send a 503 directory request code to another directory
authority
--------------------------+------------------------------------
 Reporter:  dgoulet       |          Owner:  dgoulet
     Type:  defect        |         Status:  needs_review
 Priority:  Medium        |      Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #33018        |         Points:  0.4
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by arma):

 Looks good! A small issue:

 * "is the one of a configured directory" -> "is a configured directory"

 and a bigger issue:

 * "so it might get a 503 code and thus fail the upload of its brand new
 descriptor" -- I don't think you can get a 503 in response to a post
 attempt. That is, we only check global_write_bucket_low() in five cases:
   * handle_get_current_consensus(), in response to a vanilla or microdesc
 consensus request
   * handle_get_status_vote(), for when somebody is asking for our current
 or most recent vote [that one's fun because only dir auths serve votes,
 and previously dir auths would never decide to reply with a 503]
   * handle_get_microdesc(), when somebody is asking for individual
 microdescs
   * handle_get_descriptor(), same as above but for vanilla descriptors
   * handle_get_keys(), when somebody is asking for authority certificates

   So the "To clarify further the situation:" paragraph in the commit
 comment needs to change. I think the problematic scenario is that relays
 try to fetch new consensus and descriptor documents from authorities,
 because directory_fetches_from_authorities(), but the authorities give
 them a 503 and then they don't have a proper cached version to give out
 when clients come asking, and then clients don't get their network view
 and it all falls apart.

   That's why this patch here should be ok for one or two authorities to
 run, but not more, until we also do the "whitelist relays" piece of it.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33029#comment:3>
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