simon:
> As I see it, removing via directory authority consensus is still the
> cleaner way, especially in a case of ~100 similar nodes.
>
> What came to my mind was something like a bugtracker for bad nodes.
Yes, but it's too crafty and should be done by hand. Doing so is error
prone/unstable/com
On 06.07.2016 15:50, Ivan Markin wrote:
> The introduction of peering policy definitely solves this issue in a
> transparent and harmless way. Filed a ticket #19625 [1] to move this
> discussion
> there.
On 06.07.2016 14:56, Roger Dingledine wrote:
> Speaking of which, a while ago I started a disc
s7r:
> The path of a circuit is selected by the client (i.e. user). So,
> each and every relay / bridge, in order to be considered a valid one,
> should be able to extend a circuit when requested to any other
> relay, otherwise everything gets broken.
So does everything break if there are connec
On 7/6/2016 4:50 PM, Ivan Markin wrote:
> Andreas Krey:
>> That will cause issues for everyone that happens to select your
>> relay and the 'blocked' relays in a circuit - the connections will
>> just fail, and the user will wonder what happened, and why TBB
>> doesn't work.
>
> Sure, I made a not
Andreas Krey:
> That will cause issues for everyone that happens to select your
> relay and the 'blocked' relays in a circuit - the connections will
> just fail, and the user will wonder what happened, and why TBB
> doesn't work.
Sure, I made a notice that you shouldn't do it if you care about the
On Tue, Jul 05, 2016 at 10:00:22PM -0700, Green Dream wrote:
> So... what's going on in this particular case and what are the directory
> authorities going to do, if anything?
Yesterday we started the move towards blocking them. (The move takes a
little while, since it needs a sufficient fraction
On 7/6/16, Green Dream wrote:
>> It's up to directory authority operators to deal with
>> suspicious/rogue/misconfigured relays by marking them as
>> invalid/rejected/badexit.
>
> So... what's going on in this particular case and what are the directory
> authorities going to do, if anything?
>
> A
On Wed, 06 Jul 2016 02:29:00 +, Ivan Markin wrote:
...
> But you're still able to restrict connections with these nodes using
> plain blocking at your firewall. So circuits through these relays are
> not able to be built anymore.
That will cause issues for everyone that happens to select your
On 7/5/16, Ivan Markin wrote:
>> blacklist hosts individually (unless I'm putting them into MyFamily,
That could 3rd party backfire against your relay, and must be
mutual in the consensus anyway. So don't.
> AFAIK, there is no option in tor itself to exclude relays from the routing.
>
> But you'
> On 06 Jul 2016, at 04:29, Ivan Markin wrote:
>
> simon:
>> If I understood the documentation correctly, as a node operator I can't
>> blacklist hosts individually (unless I'm putting them into MyFamily,
>> which I don't want to).
>
> AFAIK, there is no option in tor itself to exclude relays f
simon:
> If I understood the documentation correctly, as a node operator I can't
> blacklist hosts individually (unless I'm putting them into MyFamily,
> which I don't want to).
AFAIK, there is no option in tor itself to exclude relays from the routing.
But you're still able to restrict connectio
> It's up to directory authority operators to deal with
> suspicious/rogue/misconfigured relays by marking them as
> invalid/rejected/badexit.
So... what's going on in this particular case and what are the directory
authorities going to do, if anything?
As a relay operator near the top of the CW
> In good news, 91 new high speed exits means Tor network should be
> truly blazing for a while :)
these are non-exits relays (currently)
currently 93 relays (89 running):
https://gist.githubusercontent.com/nusenu/0478362226f1b74744bec8700c4a3732/raw/e8a5ed82061a2b6a83f982964794ef79c067f005/Relay
On Tue, Jul 05, 2016 at 05:10:49PM +0200, Niklas K. wrote:
> It's up to directory authority operators to deal with
> suspicious/rogue/misconfigured relays by marking them as
> invalid/rejected/badexit.
>
> Relay operators are not supposed to decide what other relays they may be put
> in a circu
It's up to directory authority operators to deal with
suspicious/rogue/misconfigured relays by marking them as
invalid/rejected/badexit.
Relay operators are not supposed to decide what other relays they may be put in
a circuit with (apart from notifying the network which nodes belong to the sam
On 05.07.2016 13:31, Xza wrote:
> 91 at the moment and they will soon gain more flags.
> https://sourceforge.net/p/nepenthes/wiki/Home/
> Seems like some sort of honeypot.
> Most seem to be from AWS & Linode & Leaseweb USA.
How does the process work to exclude nodes from the network?
If I underst
91 at the moment and they will soon gain more flags.
https://sourceforge.net/p/nepenthes/wiki/Home/
Seems like some sort of honeypot.
Most seem to be from AWS & Linode & Leaseweb USA.
On July 3, 2016 10:59:00 AM GMT+02:00, nusenu wrote:
>some new ones:
>http://article.gmane.org/gmane.network.onio
some new ones:
http://article.gmane.org/gmane.network.onion-routing.ornetradar/1468
signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/
18 matches
Mail list logo
