#29500: Broken circuitpadding unittests on appveyor -------------------------------------------------+------------------------- Reporter: asn | Owner: teor Type: defect | Status: new Priority: High | Milestone: Tor: | 0.4.0.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: wtf-pad, tor-relay, tor-cell, | Actual Points: 3 padding, 041-proposed, 040-must, tor-ci-fail- | sometimes | Parent ID: #28631 | Points: 3 Reviewer: nickm | Sponsor: | Sponsor2 -------------------------------------------------+------------------------- Changes (by teor):
* status: needs_revision => new Comment: Replying to [comment:33 mikeperry]: > I would request that we not merge hacky changes to the unittests for the #29990 workarounds. Ok, I'll close my pull requests on this ticket, and mark #29990 as 040-backport. > If we're going to hack this, let's hack it so monotime_init() (or the ratchet) has a non-zero value, and then we can go through circpad for the rare cases where the difference between monotime_init() and the first ratchet update is 0 (or negative), in production (which I still believe should be rare/impossible). These situations are rare, but they can happen. And they can happen more than you think. *Any* pre-ratchet monotime update can be zero or negative, because the Windows API and gettimeofday() don't provide monotonic source times. So any number of calls to the monotonic time functions may return the same value. Would you like to open a new ticket to test and fix these zero delta issues in circuitpad? #29990 is now about another bug, and this ticket is full of comments. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29500#comment:34> 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