#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs