[tor-bugs] #28780 [Core Tor/Tor]: circpadding: Add machine flag for not closing circuit if machine is active

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat May 11 00:18:16 UTC 2019


#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


More information about the tor-bugs mailing list