Possible race condition with truncated nicks

[emersonveenstra]

When a Client is given a nick that's longer than the server's allowed nick length, the server might silently truncate the nick. When RPL_WELCOME is sent, it changes the nick to the correct one.

However, if a user is using SASL, it emits the 'registered' event on either SASL failure or success, which is before RPL_WELCOME. So in the connect callback, if the user is using SASL, client.nick will still be the non-truncated nick. This is why things like matrix-org/matrix-appservice-irc#1393 are happening, the bridge assigns the value of client.nick in the connect callback and stores that for the duration of the connection.

I'm not entirely sure why it's emitting registered on SASL replies, since RPL_WELCOME will be sent no matter what.

[Mikaela]

Is this also the cause of matrix-org/matrix-appservice-irc#27 (comment)?

[emersonveenstra]

@Mikaela I don't know Ergo as much as I should, but if it doesn't explicitly issue a NICK on connection when it forces the nick change, then yeah, probably.

[slingamn]

If I'm understanding the context correctly, this is correct and is actually quite likely to occur with Ergo, because of force-nick-equals-account. That is to say, in the default/recommended configuration of Ergo, if a user authenticates with SASL, the nick they sent with NICK is ignored and their account name is used instead. The server doesn't send a NICK command of its own to indicate this, and the client is expected to deduce it from 001 RPL_WELCOME.