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

Re: another BADEXIT found $8424E8653469B1EFF87E79E8599933A3BAF8FDB2

To: or-talk@xxxxxxxxxxxxx
Subject: Re: another BADEXIT found $8424E8653469B1EFF87E79E8599933A3BAF8FDB2
From: Nick Mathewson <nickm@xxxxxxxxxxxxx>
Date: Tue, 10 Feb 2009 01:49:55 -0500
Delivered-to: archiver@xxxxxxxx
Delivered-to: or-talk-outgoing@xxxxxxxx
Delivered-to: or-talk@xxxxxxxx
Delivery-date: Tue, 10 Feb 2009 01:49:57 -0500
In-reply-to: <200902100510.n1A5AShm019087@xxxxxxxxxxxxx>
Mail-followup-to: Nick Mathewson <nickm@xxxxxxxxxxxxx>, or-talk@xxxxxxxxxxxxx
References: <200902100510.n1A5AShm019087@xxxxxxxxxxxxx>
Reply-to: or-talk@xxxxxxxxxxxxx
Sender: owner-or-talk@xxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)

On Mon, Feb 09, 2009 at 11:10:28PM -0600, Scott Bennett wrote:
 [...]
>      I think it would be a useful modification for the authorities to be able
> to flag IP addresses and address ranges with BadExit in addition to being
> able to flag nicknames and key fingerprints.  That way, when a case like
> "apple" arises, its career could be greatly hindered by flagging the /24's
> of their ISPs. 

Internally, this ability exists.  In the relevant configuration file,
authority operators can mark entire IP ranges as BadExit.  This
doesn't get propagated to the consensus; instead, they automatically
vote for any OR that shows up in a marked IP range as being BadExit.
The result's the same, but the client code and the consensus format
get to stay a little simpler.

yrs,
-- 
Nick

References:
- RE: another BADEXIT found $8424E8653469B1EFF87E79E8599933A3BAF8FDB2
  - From: Scott Bennett

Prev by Author: Re: another reason to keep ExcludeNodes
Next by Author: Re: Grrr...SafeLogging doesn't work in 0.2.1.12-alpha :-{
Previous by thread: RE: another BADEXIT found $8424E8653469B1EFF87E79E8599933A3BAF8FDB2
Next by thread: Re: another BADEXIT found $8424E8653469B1EFF87E79E8599933A3BAF8FDB2
Index(es):
- Author
- Thread