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