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):

 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))".

 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.

 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.

 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

 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.

 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.

 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1090#comment:39>
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