Re: [tor-bugs] #1090 [Tor Client]: Warning about using an excluded node for exit

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs