Undocumented and contradictory hostmask support in owner and admins settings

[dgw]

There is a contradiction between Sopel's docs for the core.owner and core.admins settings, and how those values are actually used.

What's wrong?

According to the docs, under both "The [core] configuration section" and "Core Config Section" pages, examples show only nicknames under both of these settings. But internally, a Trigger can treat them as user@host regex patterns, too:

sopel/sopel/trigger.py

Lines 548 to 563 in 6fc9eee

	def match_host_or_nick(pattern):
	pattern = tools.get_hostmask_regex(pattern)
	return bool(
	pattern.match(self.nick) or
	pattern.match('@'.join((self.nick, self.host)))
	)
	if settings.core.owner_account:
	self._owner = settings.core.owner_account == self.account
	else:
	self._owner = match_host_or_nick(settings.core.owner)
	self._admin = (
	self._owner or
	self.account in settings.core.admin_accounts or
	any(match_host_or_nick(item) for item in settings.core.admins)
	)

This ability doesn't appear anywhere in the documentation, perhaps because it breaks intended usage of the setting values in other places. core.owner, for example, is used in coretasks and third-party plugins as the target for important messages about the bot's configuration or errors. That value must be a nickname, not a user@host regex, for those uses to work.

How should we fix it?

We already have owner_account and admin_accounts, which are used if the server supports account-tag or otherwise attaches a services account name to messages in a way that Sopel can parse.

As a middle ground, there should exist owner_host and admin_hosts settings. The names are subject to revision, but their function is clear: Stricter controls on owner/admin identification beyond simple nickname matching, where account matching isn't available.

I propose a tiered enforcement system like this, described for owner but applied to both (just to save me some typing):

• Only owner set: Match on nickname
  • Here is the reason for putting this in 8.1.0: We need to plan ahead, add the new settings, and raise deprecation warnings for detectable cases of behavior that will be removed in 9.0, meaning @ or other nick-invalid characters in one of the owner or admins values.
• owner and owner_host set: Match on user@host
• owner and owner_account set: Match on account name
• owner, owner_host, and owner_account set: Match account name

In summary, if either host or account settings exist, nickname matching is ignored, period. The account always takes priority, same as it does now; if the IRCd has services accounts, we defer to its authorization mechanism(s).

But what about admins?

Yes, I said that the above would apply to admins, but there's another consideration: Sopel can have only one owner, but multiple admins. We might need to validate the configuration by comparing the length of admins and admin_accounts, though there are plenty of cases I could see where admin_accounts or admin_hosts would not be the same length as an admins list based on nicks only. (Grouped nicks and common host cloaks are just two of many possibilities.)