NUL (\x00) is not filtered from IRC args/text

[dgw]

Requested Feature

irc.utils.safe() strips CR and LF from its input, but not NUL (\x00) even though all three octets are disallowed in IRC lines.

sopel/sopel/irc/utils.py

Lines 20 to 48 in 3ff58c1

	def safe(string):
	"""Remove newlines from a string.
	:param str string: input text to process
	:return: the string without newlines
	:rtype: str
	:raises TypeError: when ``string`` is ``None``
	This function removes newlines from a string and always returns a unicode
	string (``str``), but doesn't strip or alter it in any other way::
	>>> safe('some text\\r\\n')
	'some text'
	This is useful to ensure a string can be used in a IRC message.
	.. versionchanged:: 7.1
	This function now raises a :exc:`TypeError` instead of an unpredictable
	behaviour when given ``None``.
	"""
	if string is None:
	raise TypeError('safe function requires a string, not NoneType')
	if isinstance(string, bytes):
	string = string.decode("utf8")
	string = string.replace('\n', '')
	string = string.replace('\r', '')
	return string

Problems Solved

Plugins accidentally sending NUL will most likely cause the server to disconnect the bot with an error ("malformed data" or similar).

Alternatives

Plugin authors must manually ensure that anything their code sends to IRC does not contain the NUL byte.

Notes

No response

[dgw]

Remembered this and finally tested it:

@plugin.command('nullme')
@plugin.require_admin("Sorry, I can't let you do that.", reply=True)
@plugin.output_prefix('[NULL] ')
def null(bot, trigger):
    """Send a message containing null, for testing."""
    bot.say("Null\x00byte!")

At least on Rizon, the bot is not disconnected; the message gets truncated:

<dgw> .nullme
<SopelGitpod> [NULL] Null

Obviously not ideal, but not as bad as it could be.