Re: [tor-bugs] #27416 [Core Tor/Tor]: Improve descriptor validation in Tor using Stem

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

#27416: Improve descriptor validation in Tor using Stem
--------------------------+----------------------------------
 Reporter:  teor          |          Owner:  (none)
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+----------------------------------

Comment (by atagar):

 > But the parsing check *still* won't be enough to catch all spec-
 implementation divergences. And that's ok. Sometimes we fix the spec,
 sometimes with fix tor, and sometimes we fix other parsers.

 Yup. Agreed. :P

 > Running stem as an essential part of dirauth operation is a significant
 change in tor's security model. It would require a proposal.

 Agreed, on reflection we shouldn't. In essence there's two directions we
 can take: use stem's validators to **notify (file tickets)** or **enforce
 (block malformed descriptors)**. We do the former nowadays, and should not
 do the later without a lot of thought.

 > If the checks are safe to make public, then send them to tor-consensus-
 health, or create another list.

 Will do! They're safe, the only reason I don't send them to the list is
 because I'm the only person that would likely act upon them. Happy to give
 it a shot.

 There's a few spots where I've created automated notifications that follow
 a certain pattern...

 1. X commonly breaks.

 2. I create a monitor to email me when X occurs.

 3. When X occurs I file a ticket with the network team.

 Honestly malformed descriptors are pretty minor pain point for me. They're
 rare (one crops up every couple months?). I'll give tor-consensus-health@
 a shot, but I have a sinking suspicion I'll still need to file tickets to
 get traction.

 Another more common annoyance for me are tor regressions. Every couple
 weeks the following occurs...

 1. Tor pushes a regression.

 2. Stem's Jenkins test failures email me.

 3. I wait a few days to see if it gets fixed.

 4. When it becomes clear a fix isn't coming I pull and compile the new tor
 codebase.

 5. I reproduce the test failure locally and construct reproduction steps
 that use telnet to take Stem out of the loop.

 6. I file a ticket with the network team to get it addressed.

 To the network team's credit their responsiveness when we get to #6 is
 **fantastic**. Only trouble is that I'd like to take myself out of the
 loop on these both (tor regressions and malformed descriptors).

 For malformed descriptors I'll give tor-consensus-health@ a shot, and
 reopen this if I still need to file a ticket.

 As for tor regressions I've asked the Network team to run tor's stem test
 target prior to pushing but no dice so far. Just dealt with another this
 morning (#27446). Any thoughts on how we can drop me from the loop on
 these?

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