Re: [tor-bugs] #13125 [Tor]: Review the guardiness python script of #9321

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

#13125: Review the guardiness python script of #9321
------------------------+--------------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  needs_review
     Priority:  normal  |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-guard tor-auth
Actual Points:          |  Parent ID:  #9321
       Points:          |
------------------------+--------------------------------

Comment (by nickm):

 * Hmmmmm.  I worry slightly about using stem for parsing here
   ... remind me, does stem accept unrecognized elements and fields and
   so forth in documents, or does it reject those?  I thought
   it sometimes needed to get patched when we added new fields.  If
   that's right, this will make us fail when the format evolves.

   * If I'm wrong about stem's behavior, great.

   * If I'm right, we need to give it a way to be more tolerant.

   * Regardless, we should make sure that we can recover from
     misformatted cnsensuses.

 * The output format should be made extensible so that it can handle more
 than
   one ID format.  Soon, Ed25519+RSA identity pairs will exist.  After
   that, Ed25519-alone will exist.

   * The schema should also probably handle this situation.

 * Probably this needs a LICENSE or COPYING file.  And a license.

 * Do we verify consensuses now?

 * README should explain how and what to backup.

 * The cron script probably shouldn't be called cron.sh, right?

   * Is the cron script smart enough to exit if something fails?

 * In guardfraction.py ... double-check that max_days is positive?  And not
 huge?

 * Check that we're not going backwards in time?

 * Do you need an index on consensus.consensus_date to make delete and
 count fast enough?

 * find_missing_hours_from_list() isn't actually right: We don't guarantee
 a one-hour timer.  Instead you need to check for gaps in the (valid-after,
 fresh-until) series of times.  But this would mean that just counting
 consensuses isn't right.  Maybe each consensus needs a duration-fresh
 field.

 * How does the nested query in read_db_file() perform?  Is it even right?
 I don't think the parentheses balance.

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