[tor-bugs] #25870 [Core Tor/Tor]: Fix vanguard restrictions

[Tor Bug Tracker & Wiki]

#25870: Fix vanguard restrictions
--------------------------+------------------------------------
 Reporter:  mikeperry     |          Owner:  (none)
     Type:  defect        |         Status:  needs_review
 Priority:  Medium        |      Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:  #25546        |         Points:
 Reviewer:  asn           |        Sponsor:
--------------------------+------------------------------------

Comment (by mikeperry):

 Replying to [comment:12 asn]:
 > Replying to [comment:11 mikeperry]:
 > > Ok I edited the commit message to clarify that A - B - A is for sub-
 paths. I also added a commit for Property 6. Otherwise asn's commits are
 taken as-is.
 > >
 > > https://oniongit.eu/mikeperry/tor/commits/bug25870_v2
 > >
 > > Leaving as needs_review for asn to have a look at the last commit on
 that branch, which does the refactoring he asked for on IRC, and gives us
 "strong" property 6.
 >
 > Sounds good. Please check my branch `bug25870_rebase` which tidies up
 the _v2
 > branch a bit by squashing a few commits and giving a more logical flow.
 Feel
 > free to not use if you don't like it. Check the diff between
 `bug25870_rebase`
 > and `bug25870_v2` to see that the diff is just comments.

 If you like this better I'm fine with it. I pushed a version to
 mikeperry/bug25870_rebase that resets the author on the commits that lost
 it during your rebase.

 > BTW, should we use `DEFAULT_ROUTE_LEN+1` in the latest commit? What
 happens in
 > the case of even longer RP/IP/HSDir circuits that could occur because of
 > cannibalization? e.g. I remember that Tor clients extend failed IP
 circuits by
 > one hop to connect to the next IP, this means that those circuits can
 end up
 > being more than 5 hops.

 I think the current code is what we want. It checks cur_len, which is not
 the desired length, but the current position in the circuit construction.
 So when we cannibalize a circuit to add another hop, it will be cur_len =
 5/6/more. The guard node will already have been allowed in the 4th
 position (and in the IP/RP). We could consider adding cases to allow those
 additional positions to also be the guard... I am not sure if that
 matters/is worth it though?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25870#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online