View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005333 | unreal | ircd | public | 2019-07-18 17:39 | 2019-10-09 18:13 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 5.0.0-alpha4 | ||||
| Summary | 0005333: U5: control channel characters / utf8 | ||||
| Description | As I mentioned in https://github.com/ircv3/ircv3-specifications/pull/342 it is a problem if non-utf8 characters are allowed in channel names. Regardless of websocket, some configuration/control is likely a good idea. At this time we don't have some kind of universal anti-look-alike system, which is what another IRCv3 effort is about.. I'm thinking of some options here like: 1. the current policy, block only ASCII <32 2. only valid utf8 3. only a-zA-Z0-9 and some characters, effectively block high ascii / block utf8 And I think the default should change from option 1 to option 2. A more security conscious decision would be option 3, due to the lack of lookalike checking, but that's too strict for a default I think. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
commit 5a57eec4c71e2d3c7144a530f3e2679c49558e97 (HEAD -> unreal50, origin/unreal50) Author: Bram Matthys <[email protected]> Date: Sun Sep 22 18:40:29 2019 +0200 Channel names must now be valid UTF8 by default. We actually have 3 possible settings of set::allowed-channelchars: utf8: Channel must be valid UTF8, this is the new default ascii: A very strict setting, for example in use at freenode, the channel name may not contain high ascii or UTF8 any: A very loose setting, which allows almost all characters in the channel name. This was the OLD default, up to and including UnrealIRCd 4. It is no longer recommended. For most networks this new default setting of utf8 will be fine, since by far most IRC clients use UTF8 for many years already. If you have a network that has a significant portion of chatters that are on old non-UTF8 clients that use a specific character set then you may want to use set { allowed-nickchars any; } Some Russian and Ukrainian networks are known to need this. Devs: src/utf8.c has been added which will be used by this and by other functionality later. |
|
|
It should be noted that clean_channelname() is only called for local creates, or at least in JOIN. I'm leaving this issue open because I still need to communicate this setting between UnrealIRCd servers. We should refuse to link if the settings differ I think since that would be a confusing situation where you can join channels on server A but not on B. |
|
|
I have the sending of PROTOCTL in my queue already, but... not yet the parsing and rejecting. Had other things to do the rest of the day. Also... we have U4 of course, so see if we could somehow warn about things but not be too noisy eg not for every remote JOIN. |
|
|
commit 22dec96f9a5dcf5edb0cb177dfed963b53b8bf62 (HEAD -> unreal50, origin/unreal50) Author: Bram Matthys <[email protected]> Date: Wed Oct 9 17:55:23 2019 +0200 No clean_channelname() anymore but a valid_channelname() function. Also, deal with servers with different set::allowed-channelchars settings: * We reject the link if set::allowed-channelchars settings differ between UnrealIRCd 5 servers. * For the case where you have a mixed network consisting of UnrealIRCd 4.x and UnrealIRCd 5.x servers we try not to desync, BUT will not allow anyone to join the invalid channels locally. For IRCOps a message is printed with additional information on such a failed JOIN attempt. See https://www.unrealircd.org/docs/Set_block#set::allowed-channelchars for the different settings, which are best and U4<->U5 advice. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-07-18 17:39 | syzop | New Issue | |
| 2019-08-18 15:14 | syzop | Relationship added | child of 0005279 |
| 2019-08-18 15:17 | syzop | View Status | private => public |
| 2019-08-18 15:29 | syzop | Status | new => acknowledged |
| 2019-09-22 18:45 | syzop | Note Added: 0020928 | |
| 2019-09-22 18:47 | syzop | Note Added: 0020929 | |
| 2019-09-22 18:47 | syzop | Note Edited: 0020929 | |
| 2019-10-06 19:52 | syzop | Note Added: 0020943 | |
| 2019-10-09 18:13 | syzop | Assigned To | => syzop |
| 2019-10-09 18:13 | syzop | Status | acknowledged => resolved |
| 2019-10-09 18:13 | syzop | Resolution | open => fixed |
| 2019-10-09 18:13 | syzop | Fixed in Version | => 5.0.0-alpha4 |
| 2019-10-09 18:13 | syzop | Note Added: 0020947 |
