passwords with colons/spaces are no longer working in some clients #835

New Issue

2026-10-05T04:47:30+02:00

adam commented

2026-10-05 04:47:30 +02:00

Users who have colons/spaces in their znc passwords aren't able to connect with some clients anymore, e.g. hexchat/mutter

This is caused by the clients as they are just sending PASS <username>/<network>:<password> instead of PASS :<username>/<network>:<password>, which marks everything after the first colon as a string. Not all clients are affected, weechat for example sends the first :.

So this isn't a bug in znc but a regression as it worked with 1.6.6.

see also:

Users who have colons/spaces in their znc passwords aren't able to connect with some clients anymore, e.g. [hexchat](https://github.com/hexchat/hexchat)/[mutter](https://www.mutterirc.com/) This is caused by the clients as they are just sending `PASS <username>/<network>:<password>` instead of `PASS :<username>/<network>:<password>`, which marks everything after the first colon as a string. Not all clients are affected, weechat for example sends the first `:`. So this isn't a bug in znc but a regression as it worked with 1.6.6. see also: - https://github.com/hexchat/hexchat/issues/1550 - https://github.com/irssi/irssi/issues/362 - https://github.com/weechat/weechat/issues/602

adam commented

2026-10-05 04:47:31 +02:00

Related: #1188 (Hexchat), #1194 (unknown)

The "right thing" was done before commit 933aa6db0c. However, for whatever reason (fix a bug which sometimes blocked login of users.????) that commit switches from GetParams(0) (get all the parameters) to GetParam(0) (get only the first parameter). Reverting that part of the commit would get most passwords working (things like two spaces or space followed by colon would still be parsed according to IRC rules and be lost and fixing this in ZNC would require working around the general parser infrastructure in this place).

Edit: ooohhhh, I see. GetParams inserts a colon again if necessary, i.e. it is meant for the construction of IRC lines and not for getting the parsed parameters out. Hm... how about doing an ugly const VCString& params = Message.getParams(); CString sAuthLine = CString(" ").Join(params.begin(), params.end()); then to get to the parameters?

Related: #1188 (Hexchat), #1194 (unknown) The "right thing" was done before commit 933aa6db0ce46353b8c18a464baad06c147c9842. However, for whatever reason (`fix a bug which sometimes blocked login of users.`????) that commit switches from `GetParams(0)` (get all the parameters) to `GetParam(0)` (get only the first parameter). Reverting that part of the commit would get most passwords working (things like two spaces or space followed by colon would still be parsed according to IRC rules and be lost and fixing this in ZNC would require working around the general parser infrastructure in this place). Edit: ooohhhh, I see. `GetParams` inserts a colon again if necessary, i.e. it is meant for the construction of IRC lines and not for getting the parsed parameters out. Hm... how about doing an ugly `const VCString& params = Message.getParams(); CString sAuthLine = CString(" ").Join(params.begin(), params.end());` then to get to the parameters?

adam commented

2026-10-05 04:47:32 +02:00

@psychon yep. Or we can let clients fix what they send to follow RFC instead. In any case there is a workaround to not have spaces in password.

@psychon yep. Or we can let clients fix what they send to follow RFC instead. In any case there is a workaround to not have spaces in password.

adam commented

2026-10-05 04:47:32 +02:00

update: the issue has been fixed in mutter and hexchat

update: the issue has been fixed in mutter and hexchat

adam commented

2026-10-05 04:47:33 +02:00

With ZNC 1.8.2 and HexChat 2.16.1, a password with a colon in the middle (no spaces) still doesn't work with HexChat. I was able to make it work by prepending the password with : in HexChat's configuration UI. Not sure whether that's a HC bug or a ZNC bug. (I assume the latter because a password with a colon in the middle is still one term, per the IRC spec. But I didn't check the actual TCP traffic to be sure what HC is sending in either case.)

With ZNC 1.8.2 and HexChat 2.16.1, a password with a colon in the middle (no spaces) still doesn't work with HexChat. I was able to make it work by prepending the password with `:` in HexChat's configuration UI. Not sure whether that's a HC bug or a ZNC bug. (I assume the latter because a password with a colon in the middle is still one term, per the IRC spec. But I didn't check the actual TCP traffic to be sure what HC is sending in either case.)

adam commented

2026-10-05 04:47:34 +02:00

@Arnavion that's a completely different issue, and is actually a feature, not a bug. Some clients don't let users easily configure username to send to server, so ZNC provides a workaround: if password contains :, it parses username from the "password" received from client. And if the username part of it (to the left of :) is empty, it still uses what was sent in USER

@Arnavion that's a completely different issue, and is actually a feature, not a bug. Some clients don't let users easily configure username to send to server, so ZNC provides a workaround: if password contains `:`, it parses username from the "password" received from client. And if the username part of it (to the left of `:`) is empty, it still uses what was sent in `USER`

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#835