Why does ZNC ship with *NickServ and *Q? #436
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/znc#436
Reference in new issue
Block a user
As far as I am aware, *q is only supported on Quakenet and nowadays there aren't many networks that have NickServ, but don't support SASL. I am only able to name two (OFTC has *cert though) networks where there is NickServ without SASL, but *NickServ module didn't even to do anything there. I think they used HybServ2.
It looks to me like they could be external modules.
Update: according to #znc at freenode, there are multiple networks with NickServ, but without SASL. *perform would probably work as well with them though.
--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/7191226-why-does-znc-ship-with-nickserv-and-q?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).Is the Q module still maintained? https://github.com/znc/znc/issues/554 is something I reported a long time ago and still seems to be in znc 1.4. (It also doesn't seem to work since I constantly need to auth myself; I'll need someone else to confirm that.) Also sending /msg *q HELP returns a bunch of unrelated WHOISes. But the fact it allows you to use challenge authentication is nice.
I think NickServ should remain, I personally still use it on networks that do not support sasl.
I believe it is maintained, because it's still in this repository and #602 is marked into the 1.6 milestone.
Are you asking because the function of *NickServ can be effectively duplicated in *Perform ?
Biggest difference is the *NickServ module won't use
/ns identify YourNick YourPasseven if that's available, though it's a far better method if that's available. Pretty much only old Anope 1.8.x (and older, if there are any) networks lack this.Ben
Yes. The *NickServ module also appears to be a little unreliable and if I understood correctly, it also requires NickServ language to be set to English.
This starts looking like security issue to me.
Is Anope 1.8.X even supported (by Anope)?
That's correct. *NickServ works by watching out for the private notice prompting you to identify.
Agreed. On many (most?) IRCds in use, the /ns and /nickserv server-side alias shortcut will only function if the target is on a U-lined server, which in most cases is services.
Furthermore, the module does no checking of any sort about whether "NickServ" is in fact the real NickServ. It relies on the dangerous assumption that only the real NickServ will use "NickServ" . In the IRC network community, it's considered a de-facto best practice to ban the use of "NickServ" so only the real NickServ can use "NickServ" but this isn't always the case. Even on places such as Freenode, where security is taken seriously, it has been known to happen at times that someone unauthorized will have the NickServ nick, even if only for a few minutes.
I don't believe so. However, there are still a frighteningly large number of networks that continue to use it, including some rather large ones.
Other comments
To be fair, *NickServ does have the notable advantage of sometimes working if you somehow connect to a split IRC server and NickServ comes online after the connection has taken place. This is probably the strongest argument in favor of keeping *NickServ . This is an advantage that *Perform and *Sasl don't have.
However, that functionality will only sometimes work. It relies on the user using his preferred nick at the moment NickServ comes back online. This may or may not be the case for any number of reasons.
Other than that, *NickServ serves little purpose. But, this is probably why ZNC has *NickServ and why it won't eventually be deprecated.
That said, *NickServ could stand to be improved. For one, it could possibly use some sort of coding logic to ensure that "NickServ" is in fact the real "NickServ" . However, to do so reliably doesn't come without it's own technical challenges. Another idea is to integrate the *KeepNick functionality into *NickServ, possibly somehow running
/ns ghost PreferredNick Passwordfollowed by/nick PreferredNickor even/ns regain PreferredNick(if supported).Ben
*Cert has this too, but it's not so widely supported, but it doesn't look so much difficult from SASL EDSCA-CHALLENGEAUTH (sorry for misspelled name, I don't ever remember it). There is also https://github.com/ircv3/ircv3-specifications/issues/103 which could help *Sasl to do this too.
By the way, could *sasl do that even now? https://github.com/atheme/atheme/pull/415#issuecomment-66869694 hints something like. (but this would break standards :()
Possibly. I'd have to dig deeper into the code to be sure. If not, I can't imagine it'd be that hard to implement.
This is a nicer approach but there's not even a draft standard yet, and of course no IRC services software and/or IRCds support this yet. The question is what to do in the meantime.
Ben
Apparently, it's not. @ahf ping?
Dropping Q module (aka making it external, and letting ahf to maintain it outside of ZNC repo) would solve this issue, and will help with #1494
I have completely overlooked #554. I'm not using the Q module anymore and I'm hardly active on Quakenet either.
I could take a look at #554 during the upcoming week. I don't think I'm the right person to take the decision if the Q module should be maintained externally, internally, or dropped -- I don't know how many znc users that are using it. If #554 is the "only" issue right now I don't see why it would make sense to remove it though. It's not like the Quakenet development community releases early and often! :-)
Or roll the Q module into #1496? As long as auth modules are being consolidated, why not?
Because Q is useful on a single network, while sasl and nickserv are useful much more widely. But every single piece of code is an additional burden for maintenance.
I also don't think it's a good idea to merge it into a module that tries to standardise the authentication schemes used on the more up-to-date networks. To put it bluntly, I personally think the Quakenet authentication scheme should be avoided. I hope nobody else is using it.
Without ZNC sending us its usage stats, it's really hard to tell.
I didn't drop it before because you wanted to look after this module and had a strong opinion on having it in ZNC repo. I'll drop it after 1.7 then, which is exactly the same as making it external - it's only a matter of updating URL to the "fresh" version here
Cool, thank you! Sounds good to me.
I haven't noticed this is still open after #1653