Re: [tor-bugs] #22029 [Core Tor/Tor]: Allow ed25519 keys to be banned in the approved-routers file

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#22029: Allow ed25519 keys to be banned in the approved-routers file
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  neel
     Type:  enhancement                          |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.3.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  034-triage-20180328,                 |  Actual Points:
  034-removed-20180328                           |
Parent ID:                                       |         Points:  1
 Reviewer:  nickm                                |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Sorry for the delay -- I tried to get up to speed with the history here,
 but there are so many fixup commits that I'm having a pretty hard time.  I
 tried to make a squashed version of the branch, but I got conflicts when
 rebasing.  So instead I just looked at the list of changed files, using
 --color-moved so that I could see where the code movement was versus the
 changes.

 I left some comments on PR (970), but: there is a tricky problem here that
 will cause a problem if we can't fix it.

 The problem is the new ed25519 public key field in routerstatus_t.  It
 doesn't belong there, and it is only set when the authority is deriving
 the routerstatus_t from a routerinfo_t.  That means that the authority
 won't have this ed25519 public key field set when it is looking at a vote
 or a consensus, and deciding whether to download a routerinfo that it
 doesn't know about.  So the authority is at risk of downloading a
 routerinfo_t that it would reject, then rejecting it, and immediately
 deciding to re-download it, over and over.  This is exactly what
 dirserv_would_reject_router() is supposed to prevent.

 To fix this problem, there seem to be two things we can do:
   1. We can have dirserv_would_reject_router() take a vote_routerstatus_t
 instead of (or in addition to) a routerstatus_t.  This would only be
 workable when parsing a vote, not when parsing a consensus.
   2. We can change the way that rejected routers are handled when we
 download them: instead of rejecting them and marking them not-present, we
 can also mark them as permanently un-downloadable somehow.

 Does this make sense?  If not I can try to explain some more.

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