Out-of-order cmd with irc client quassel about reliable-discord-client-irc-daemon HOT 4 CLOSED

Hi,

Mostly implemented IRC based on how ERC and ZNC clients work here, checking specs where it's unclear what is happening, so definitely possible that there will be quirks.

In this case, checked specs out of curiosity, and it looks like a bug in Quassel, actually:

• https://ircv3.net/irc/ says: The primary core IRC protocol specifications are RFC1459, RFC2812 and RFC7194.

• https://tools.ietf.org/html/rfc1459#section-4.1 says: A "PASS" command is not required for either client or server connection to be registered, but it must precede the server message or the latter of the NICK/USER combination.

• https://tools.ietf.org/html/rfc2812#section-3.1.1 says: The PASS command is used to set a 'connection password'. The optional password can and MUST be set before any attempt to register the connection is made. Currently this requires that user send a PASS command before sending the NICK/USER combination.

But don't think specs matter much, if they differ from de-facto behavior, especially with regards to such minor stuff, so guess I'll fix that as you suggested.

This one is more interesting:

when I use a irc server password I also have to allow 'pass' in check_access

As pretty sure PASS command is the one that shouldn't have check_access in it, as it's the one allowing access - will check too, gotta be a bug somewhere :)

from reliable-discord-client-irc-daemon.

pretty sure PASS command is the one that shouldn't have check_access in it

Oh, right, guess it's also being front-loaded before finishing capability negotiation, breaking mini-state-machine in check_access.

State machine there goes through following sequence:

• "capability negotiation" - only cap and quit commands
• "authentication" - cap, user, nick, pass, quit, ping
• "normal operation" - user/pass will give "You may not reregister"

Looks like quassel is sending all auth stuff before capability negotiation phase ends, which is weird, but probably easy to support too.

from reliable-discord-client-irc-daemon.

As capability negotiation is independent from auth (and really is just a stub here), there doesn't seem to be any problem in the code to just allow both at the same time.
And it definitely should be supported according to https://ircv3.net/specs/core/capability-negotiation - Quassel doesn't do anything wrong in above debug log if PASS is disabled.

from reliable-discord-client-irc-daemon.

Can confirm the fix works. Thanks for the quick turnaround

from reliable-discord-client-irc-daemon.