[tor-bugs] #1090 [Tor Client]: Warning about using an excluded node for exit
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Fri Mar 25 19:06:27 UTC 2011
#1090: Warning about using an excluded node for exit
---------------------------+------------------------------------------------
Reporter: Sebastian | Owner: nickm
Type: defect | Status: needs_review
Priority: major | Milestone: Tor: 0.2.2.x-final
Component: Tor Client | Version: 0.2.1.19
Resolution: None | Keywords:
Parent: | Points:
Actualpoints: |
---------------------------+------------------------------------------------
Comment(by nickm):
Replying to [comment:39 nickm]:
> Okay, let's start reading though this. Only 800 lines; how bad could it
be?
>
> general observation 1: we should make it so that
routerset_contains_foo(set, foo) returns false if set is NULL. That would
simplify our code a fair bit. [oh wait, it does! We should just simplify
all the "if (excludeFoo && routerstet_contains(excludeFoo, foo)" lines to
"if (routerset_contains(excludeFoo, foo))".
I'm going to add this as a new ticket: #2797
> general observation 2: setting StrictNodes will get you a whole lot of
warnings. That's probably fair.
>
> re 470005bca: "refuse excluded hidserv nodes if strictnodes": I think
that the approach of removing hidden service introduction points from the
service descriptor is wrong: If the user changes their ExcludeNodes or
StrictNodes settings, their hidden service won't start working.
I've got a patch for this in my branch.
> re d924435c: changing the interface to routerset_get_all is needless; we
already have routerset_subtract and routerset_get_disjunction.
>
> Also, this exposes a hole in my documentation: it didn't say what should
happen when every member of EntryNodes or ExitNodes is excluded and
StrictNodes is 0. I think that warning the user and giving up is a fine
thing to do in this case.
I've added a patch to my manpage branch explaining that ExcludeNodes
overrides EntryNodes.
> re 65dae3aa: the warning messages should probably say what directory
activity we were thinking of doing when we ran into the excluded node.
>
> The behavior of directory_initiate_command_routerstatus_rend is kinda
broken and perhaps we should treat it as a bug. In fact, we should
backtrack to figure out why we might pick a router for a given directory
operation if that router would be excluded.
>
> The router_pick_directory_server_impl and
router_pick_trusteddirserver_impl functions do the wrong thing if every
potential directory is excluded and StrictNodes is 0.
>
> re e9f91b2f5291cd9c: I say that we just "#if 0"
circuit_conforms_to_options for 0.2.2. In 0.2.3, it should live, and we
should enlarge the set of circuit purposes to the point where it's
actually able to work right.
>
> re c16378a83cc1051: looks good.
>
> re bac8bdb400eff: seems okay
On review, I think Sebastian's objection is right. This isn't a new
change in arma's patch, though. I've added an XXX022-strict for it.
> Aside: We don't support IPs and countries in the EntryNodes list. We
should fix that in 0.2.3.x. In 0.2.2, we should fix my manpage writeup to
say so.
Added this as bug2798, clarified in my desired_node_behavior branch.
> re 5535f0791d8d: This seems plausible, but it deviates from my writeup:
disallowing general exits from ExcludeExitNodesUnion means that
ExcludeNodes and ExcludeExitNodes are given the same force here regardless
of the value of StrictNodes.
>
> re 81c069f21a4039: same as above.
Changed the tor.1.txt in my desired_node_behavior branch to note this.
> re commits that only add an XXX022: we currently have 34 xxx022s in
maint-0.2.2. This adds 8. I suggest that we tag them with
XXX022-strictnodes so we can grep for those in particular.
I've changed these to "XXX022-1090".
Thus, at this point, as of the head of my bug1090-part1 branch, so far as
I know, the problems are entirely in things labelled XXX022-1090.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1090#comment:42>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list