On Sat, Jan 2, 2010 at 10:43 AM, Vin King <vin.king@gmail.com> wrote:
/cs sop #test add *!*@* [11:36.43] Notice[ ChanServ [ *!*@* already exists on the AKick list of #test ] Well, this kind of strongly suggests the refusal to add something on another list is not a security feature, but more like a "quirk" or mere side-effect of the underlying implementation. .
ChanServ won't allow you to add entirely wildcarded entries to the SOp list. It's probably just naively comparing the mask you type, to exclude that one special case.
I still think the ability to add access list entries by hostmask is valid. If I own a channel, and I know my ops don't always identify before joining, but I want them still opped when they join, I can give them hostmask
The functionality is redundant. If you have IDENT ON, the entries by mask don't grant ops. If you have IDENT OFF, the individual channel operators can use their NickServ Access lists for this, and there is no need to list the mask on the channel itself. In either case, in the present internet, it's a huge security risk, much larger than it was 16 years ago, and the AOP/SOP functionality has stayed basically the same all through this time, despite changes in the threat environment; present day prevalence of botnets, zombies, and proxies-for-hire, listing access by IP address is like hanging a "pwn me please" sign on your channel. The default behavior at least should protect channels against simple spoofing, and not encourage insecure practices. We don't need to give users the equivalent of a POP3 mail account that only authenticates you by IP address, to access your e-mail, or whatnot.
entries. Or if I own an ISP or whatnot, and I have a channel for it on DALnet, and I want anyone who is from my domain to have ops on join, there we go.
This opens the channel to similar types of abuses that occur when *!*@* is AOP'ed One bad kid using the ISP, or one open proxy, can result in a real mess, that can't easily be mitigated (without removing the overly broad mask, anyways). -- -J