James Hess wrote:
It seems like a really a bad idea to introduce any new modes that /INVITE cannot override, as it introduces new poorly-understood methods that can be used by a channel hijacker/taker-overer.
That was my concern when we added that cmode, I didn't want it to be used as a takeover tool.
Can you guarantee that all IRC servers perform SSL/TLS encryption of all traffic between servers, and no non-SSL-connected IRC server is capable of JOINing a user to the channel or effecting it in any manner so as to alter settings or receive traffic from the channel?
Can you guarantee a user hasn't telnetted into a server and run an IRC client from it?
A user can't, that's why I didn't think it would be a big deal. One shouldn't consider a public channel secured anyway, way too many things can make it unsecure without them even knowing. Vin King wrote:
For 2, I suspect this mode should be modeled after the behavior of +O. I haven't played with +S much yet, is that how it currently behaves?
cmode +S currently behaves like other cmodes (such as +O), people can bypass it with /invite and the invites list (and while riding a netsplit). We have ways to really enforce a channel to be +O unlike +S, though. Bradley Claghorn wrote:
I'm a bit confused. So these checks are not currently working? I would assume things would work exactly as Kobi mentions.
Those checks were not implemented on DALnet (yet) due to the above reasons. With that said, we understand the concerns about it and we are considering other options to make sure it won't be used to takeover channels (such as having an mlock of -S by default). -Kobi.