Re: [tor-relays] General overload -> DNS timeouts

2021-11-07 Thread nusenu
Hi, since out of 447 exit relays that support the new overload system (it got added in tor 0.4.6.x that recently hit the torproject's debian repo) over 400 (minus those affected by an onionoo bug) are overloaded as per tor's definition of it, I'll write some general recommendations for the DNS ti

Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs

2021-11-07 Thread Georg Koppen
nusenu: I think I have some general questions to begin with: 1) What part should the proposal you brought up play in the overall goal of limiting impact of malicious relays? You write """ Therefore we propose to publish relay operator trust information to limit the fraction and impact of malici

Re: [tor-relays] Compression bomb from dizum

2021-11-07 Thread Toralf Förster
On 11/6/21 10:39 PM, Logforme wrote: Got the following in my log today: Nov 06 18:19:01.000 [warn] Possible compression bomb; abandoning stream. Nov 06 18:19:01.000 [warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 45.66.33.45:80).

Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs

2021-11-07 Thread nusenu
Hi, Sounds good. I read a couple of days ago[1] that there will be a new iteration of your draft available (shortly). I am happy to give further feedback while going over the new version, once it is ready. the changes are already done, but were less significant than expected since some commen

Re: [tor-relays] [Looking for feedback] An easier way to declare families

2021-11-07 Thread Nick Mathewson
On Sun, Nov 7, 2021 at 1:36 AM Scott Bennett wrote: > > > Because the obvious incentive for cheaters is in the direction of > trying > to get clients' route selectors to choose routes through more than a single > relay operated by a given cheater, rather than the other way around, this > loo