View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006630 | unreal | ircd | public | 2026-06-21 19:24 | 2026-06-23 18:27 |
| Reporter | progval | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 6.2.6 | ||||
| Summary | 0006630: CAP LS * reply is sent to non-302 clients | ||||
| Description | The "CAP LS *" syntax, which allows sending more than one line of capabilities, is an extension of the capability negotiation version 302: https://ircv3.net/specs/extensions/capability-negotiation#cap-ls-version-features But with recent additions to the list of capabilities (coincidentally "draft/multiline", which is unrelated to multi-line CAP LS), Unreal's response to "CAP LS" that are not "CAP LS 302" no longer fits on a single line, causing Unreal to violate the spec: The solution to this is to omit some capabilities to clients that don't support version 302. I guess Unreal (or its modules) could hardcode a set of "old" capabilities, as clients not supporting version 302 are unlikely to support recent and complex specs like multiline, chathistory, labeled-response, or metadata. | ||||
| Steps To Reproduce | With latest commit (UnrealIRCd-6.2.6-rc1): 1782036556.641 bar -> S: CAP LS 1782036556.641 bar -> S: NICK bar 1782036556.641 bar -> S: USER u s e r 1782036556.641 bar -> S: CAP END 1782036556.641 S -> bar: :My.Little.Server CAP * LS * :unrealircd.org/link-security unrealircd.org/plaintext-policy unrealircd.org/history-storage draft/metadata-notify-2 draft/metadata-2 away-notify invite-notify extended-join userhost-in-names multi-prefix cap-notify setname tls chghost account-notify message-tags batch server-time account-tag echo-message labeled-response draft/chathistory extended-monitor standard-replies no-implicit-names draft/no-implicit-names draft/extended-isupport draft/multiline 1782036556.641 S -> bar: :My.Little.Server CAP * LS :unrealircd.org/json-log | ||||
| 3rd party modules | |||||
|
|
Have to say my first instinct is like jesus.. CAP 302 is almost 9 years old!!! :D But, yeah, I will do something along the lines what you suggested, i will take care of it, thanks for the suggestion. Like I can scratch 3 for sure, like the informative ones that are useless without value anyway (so less-than-302)... you know, link security, plaintext policy, and a 3rd one i now forgot. But will probably do it the other way around: have some marked as "always advertise these because less-than-302 may need these" ProgVal: Do you know of any major clients that don't support 302? I hope it is very marginal? Just checking... it may influence what caps i enable for the "less-than-302 too" :) EDIT: Oh and I may do a more quick-hack-fix for 6.2.6 since it is already in rc1 stage, do a more proper fix later, but this aside |
|
|
According to https://ircv3.net/software/clients there is a bunch, including popular and/or maintained clients, primarily KVirc |
|
|
I noticed Pidgin 2.x does not even use CAP LS, but only CAP REQ :sasl, so that is good to know. AI says KVIRC supports receiving continuation lines (302-style) even though it send "CAP LS" and not "CAP LS 302" but in that way it is just lucky (and to be clear, it does not support full 302 responses like it doesn't parse name=value). Other than that I didn't research much. I hope you can slap some people that they should be using 302, it's almost 9 years old after all, and this is or won't be an UnrealIRCd-only problem :D Anyway, for now we are good. Not that we fixed the underlying code but... the symptom is unlikely to happen for the next year or so... i hope... https://github.com/unrealircd/unrealircd/commit/684f6515d4ff49a8334ebb07d5ef01735fed29c7 commit 684f6515d4ff49a8334ebb07d5ef01735fed29c7 (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD) Author: Bram Matthys <[email protected]> Date: Mon Jun 22 09:00:30 2026 +0200 "CAP LS" may only respond 1 line, we now advertise less. "CAP LS 302" unaffected. When not using version 302, such as with "CAP LS", the specification does not allow us to use continuation lines. This means all advertised caps must fit into one line. That is no longer always the case, especially if you load 3rd party capabilities. So we need to scratch advertising some capabilities to <302 clients. "CAP LS 302" is unaffected. Note that version 302 in the specification exists since at least November 2017, so most clients use that one. According to https://ircv3.net/software/clients the following clients are affected by this change: Desktop Clients * KVIrc * Circe * catgirl * BitchX * Pidgin * LimeChat Mobile Clients * IRC for Android * LimeChat And various older versions of other clients (obviously). NOTE: The source is only that IRCv3 page. I did not check manually. For this particular commit. We filter out various unrealircd.org informative CAPs and the vendor specific json-log. So that isn't much of a problem. However, in the future we may be forced to filter out more capabilities to make room. It would be much better if all clients are on >=302. Also, I should mention we are not the only IRCd out there, so I can't vouch on what other IRCds (will) do when hitting this non-302-limit. Reported by ProgVal in https://bugs.unrealircd.org/view.php?id=6630 |
|
|
EDIT: Sorry updated last comment to fix false claim regarding KVIrc. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-06-21 19:24 | progval | New Issue | |
| 2026-06-21 19:49 | syzop | Assigned To | => syzop |
| 2026-06-21 19:49 | syzop | Status | new => acknowledged |
| 2026-06-21 19:49 | syzop | Note Added: 0023687 | |
| 2026-06-21 19:51 | syzop | Note Edited: 0023687 | |
| 2026-06-21 20:03 | progval | Note Added: 0023688 | |
| 2026-06-23 18:22 | syzop | Status | acknowledged => resolved |
| 2026-06-23 18:22 | syzop | Resolution | open => fixed |
| 2026-06-23 18:22 | syzop | Fixed in Version | => 6.2.6 |
| 2026-06-23 18:22 | syzop | Note Added: 0023689 | |
| 2026-06-23 18:25 | syzop | Note Edited: 0023689 | |
| 2026-06-23 18:25 | syzop | Note Added: 0023690 | |
| 2026-06-23 18:26 | syzop | Note Edited: 0023689 | |
| 2026-06-23 18:27 | syzop | Note Edited: 0023689 | |
| 2026-06-23 18:27 | syzop | Note Edited: 0023689 | |
| 2026-06-23 18:27 | syzop | Note Edited: 0023689 |
