Disallow producing NULL with escape sequences & prevent overflow

[wismill]

NULL usually terminates the strings; allowing to produce it via escape sequences may lead to undefined behaviour.

• Make null escape sequences (e.g. \0 and \x0) invalid
• Introduce the new message: XKB_WARNING_INVALID_ESCAPE_SEQUENCE.
• Prevent overflow (e.g. \400, \777)
• Improve log messages.
• Add corresponding tests.

Fixes #363

[bluetech]

Great catches, thanks.

[bluetech]

NULL -> NUL

[wismill]

Actually, the character name is NULL. NUL is the ASCII abreviation. I prefer the name, but if you prefer the abbreviation then I suggest we use \NUL instead.

[wismill]

Rebased with review fixes.

@bluetech @whot this PR is only about \NUL character, but I wonder if it make sense to allow the other control characters.

[bluetech]

this PR is only about \NUL character, but I wonder if it make sense to allow the other control characters.

Is there a reason to prevent it?

[wismill]

Well, I wonder if some strings are exposed and where. They might be exposed by some of the log entries, currently unescaped. They could be exposed by functions like xkb_keymap_layout_get_name and those in xkbregistry, but I would have to investigate this carefully. My point is after discovering the \NUL improper handling, there may be insufficient filtering and/or escaping that the users of the API are unaware of. Also, because there is no explicit encoding, I am not sure how the char* are interpreted. In xkeyboard-config they are all ASCII if I am not mistaken, but there could be a way to craft malicious XKB files. It would not be an issue for xkbcommon itself, but could create problems for its users.

Just thinking out loud here; we should deal with it in a dedicated issue if relevant.

[bluetech]

there could be a way to craft malicious XKB files

I have thought about this topic before.

My assumption is that xkbcommon, being a huge custom parser written in C in the 90s, is not safe from malicious input. So the question is whether there is a threat model in which xkbcommon is fed untrusted keymaps. In the cases I know and could think of, xkb keymap input comes trusted sources, like a compositor, X server, /usr/share, user's $HOME, xkbcli flag. If any of those are compromised then something has already gone wrong. (Maybe a malicious person posting a "Try my awesome keymap" post on the internet, causing users to download and "execute" it)?

Of course this is no excuse to make xkbcommon full of holes, and we even have a rudimentary fuzzer, but it does make me weigh compatibility more than malicious input.

[wismill]

@bluetech let’s continue this discussion in private. It is far too serious a topic.

[wismill]

Rebased & improved commit message. Will merge when CI is successful.