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

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

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

Comment (by teor):

 Replying to [comment:1 atagar]:
 > ...
 > > 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.

 The network team has weekly rotations. Checking for consensus health
 issues could fit in the CI/Coverity rotation.

 *But* consensus-health is really noisy. And people need to specifically
 subscribe to get the emails. Maybe there's a better place we can put this
 status?

 Can we run a scheduled task in Jenkins or Travis?
 (Travis can run scheduled tasks every day.)

 > 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.

 If we can make these failures visible, a team rotation could help.

 > 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.

 The network team member doing the CI rotation should catch these issues.
 But I bet that we are just checking for tor failures, not stem failures
 due to tor.

 > 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?

 We only recently set up the team rotations. We're going to talk about them
 again in Mexico. Let's make sure we put stem and consensus-health on the
 list.

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