Open DanielOaks opened 7 years ago
Initial KLINE implementation written in 4168eaafbb1f857bec67416464e6a3c43de66e29, roughly tested and should provide everything we want it to provide (aside from removing all clients that already match it).
KLINEs are a weird case because whether they match or not can change after joining (i.e. on nick change / etc) so I'm a bit iffy on whether to check it after those as well or to leave it.
Y'know, the "insane" style protections here would be great. Banning 99% of your net in one command isn't that nice.
The 'insane' protections should be evaluated on each addition of a new KLINE/DKLINE. If it matches the given amount of the net, then it should require adding the param INSANE
to the command, same as you need to add MYSELF
if the ban matches the client setting it.
Removing the clients when the ban is set is a weird one... Insp configures it by the type of line. I think that's fine, but maybe it'd appropriate to have it as an option when setting the ban too, like ANDKILL
just after.
Example:
KLINE ANDKILL MYSELF INSANE 127.0.0.1/2
ANDKILL
param added with ebb9d629d75c59dc2e36de5fda6b0c985ae5dc44
I'll add an xline configuration section to configure both default to killing on ban, and to set the insane level. Because without the config section they default to the current behaviour, nothing to worry about \o/
Proposal: ignore DLINEs against loopback IPs, since they could be nearly impossible to reverse.
DLINE
DLINE
themselves. ( f1e2c54fca57359fa0ce1a73d56bf52245ed6f74 )KLINE
KLINE
themselves (initial implementation)