[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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

 Replying to [comment:39 nickm]:
 > 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.

 I agree wrt what we should do if every node is excluded. Should we tell
 the user that some of their entrynodes are covered by excludenodes? This
 could be helpful if they wonder why their entrynodes isn't obeyed, but it
 could be quite spammy too once we allow countrys/IP ranges in entrynodes.

 > re bac8bdb400eff: seems okay

 I think the "be flexible about families" is going to get us nasty looks. I
 think we should always fail or we should honor StrictNodes here.

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

 About using ourselves for a reachability test: Yes, let's make it fail. If
 someone complains that they can't be a relay because they set
 excludeexitnodes, we can easily tell them to run a second Tor instance for
 their client needs.

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