#28780: circpadding: Add machine flag for not closing circuit if machine is active -------------------------------------------------+------------------------- Reporter: asn | Owner: (none) Type: defect | Status: | needs_revision Priority: Very High | Milestone: Tor: | 0.4.1.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: wtf-pad, tor-relay, tor-cell, | Actual Points: 6 padding, 041-proposed, network-team- | roadmap-2019-Q1Q2 | Parent ID: #28634 | Points: 5 Reviewer: asn | Sponsor: | Sponsor2 -------------------------------------------------+-------------------------
Comment (by mikeperry): Replying to [comment:37 asn]: > FWIW, I did some testing with the latest of this branch and #28634, and I can confirm that this branch will eventually close the padding circuit as intended. Out of curiosity, did you discover this through a malfunctioning machine that deadlocked and hit the 1.25 hour timer, or with a well-behaved machine? I have been brainstorming for other failure modes, and I realized that malfunctioning machines can get caught in infinite padding loops -- as long as cells are being sent to each other, they will stick around (because that last_cell_time_sec field will keep getting updated due to the sent and/or received cells). I think this type of error is best safeguarded against by specifying padding limits on the machines, though, as I just suggested in ticket:28634#comment:23. I will add unit tests to cover this new expiry timer, and I will think more if anything can be tweaked in circuit_expire_old_circuits_clientside(), but right now I'm not seeing anything that will further address the immediate concerns of additional circuit-leak risk and code clarity, but I'm open to suggestions. I am tempted to say that refactoring how circuit_mark_for_close vs circuit expiry vs circuit build timeout vs measurement circuits vs pathbias vs padding takeover vs cannibalization vs other purpose changes all interact with circuit shutdown should be done in a modularization-sponsored ticket. There are lot of things that could benefit from some refactoring wrt circuit ownership, timeout, expiry, and shutdown paths, and I don't think it's the best move to rabbit hole down them under Sponsor2 if we can keep this particular change low-risk. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28780#comment:38> 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