[tor-bugs] #17668 [Tor]: moria1, with updated v3 cert: Bug: Generated a networkstatus consensus we couldn't parse.

[Tor Bug Tracker & Wiki]

#17668: moria1, with updated v3 cert: Bug: Generated a networkstatus consensus we
couldn't parse.
------------------------------------------------+--------------------------
 Reporter:  arma                                |          Owner:  nickm
     Type:  defect                              |         Status:  accepted
 Priority:  High                                |      Milestone:  Tor:
Component:  Tor                                 |  0.2.7.x-final
 Severity:  Blocker                             |        Version:
 Keywords:  201512-deferred, TorCoreTeam201602  |     Resolution:
Parent ID:                                      |  Actual Points:
  Sponsor:                                      |         Points:
------------------------------------------------+--------------------------

Comment (by nickm):

 Hi, sebastian!  I'll go over the other stuff the next time I'm working on
 the code, but I hope I can answer the questions you're blocking on so you
 can review the rest.

 > the function name is networkstatus_parse_vote_from_string() - that seems
 misleading if we're treating consensuses?

 Yes, but that commit is only fixing log messages.  I'd be happy to rename
 that to networkstatus_parse_from_string, but that seemed like a separate
 issue to me.

 >I'm unsure this is sufficient. Can't we still construct a consensus from
 a situation where (consider attacking relays): [...]

 Ah, you found a bug.  Great!

 The situation you describe is supposed to be handled by
 dircollator_collate_by_ed25519().  The change in
 3941fa64ccf10dda5ac224bb1160564581c0e213 only makes sure that the
 individual votes are conformant (by not having duplicate ed keys).

 I'll walk through what's supposed to happens.  The voters say:
 {{{
 V1 says: <RSA_1, nil> <RSA_2, nil>
 V2, V3, V4, V5 all say: <RSA_1, Ed_1>
 V6, V7, V8, V9 all say: <RSA_2, Ed_2>
 }}}

 First, we have already walked through the list of votes and passed each
 one to dircollator_add_vote.  Let's assume we added them in the order
 V1...V9.  So the internal state of the dircollator is:
 {{{
   by_rsa_sha1 =
       RSA_1: { V1:<RSA_1, nil>, V2....V5:<RSA_1, Ed_1>, V6...V9: NULL }
       RSA_2: { V1:<RSA_2, nil>, V2....V5:NULL, V6.....V9:<RSA_2, Ed_1l> }
   by_both_ids =
      <RSA_1, Ed_1>: { V1: NULL, V2...V4:<RSA_1, Ed_1> V6...V9:NULL }
      <RSA_2, Ed_1>: { V1...V5: NULL, V6...V9:<RSA_2, Ed_1 }
 }}}

 In the first loop in dircollator_collate_by_ed25519(), we will find that
 no entry in the by_both_ids map has >5 entries.  So we will do nothing in
 that loop.

 In the second loop, we will add all of the entries for RSA1, and all of
 the entries for RSA2.  So it looks like we have added two separate routers
 with the same Ed key, right?

 Well, note that the ed25519_reflects_consensus field wasn't set in these
 cases, so we're supposed to leave off the "ed25519 id" when we make the
 microdescriptors, and possibly take it into account in
 compute_routerstatus_consensus() .

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