Loose port of 6ea60b2297948211925e22bd1f284179d680b4ae. I've chosen to
reduce indentation where it's convenient, and I'm allowing >-[0-9] as a
way of specifying a minimum of 0 because... I don't know, it just seems
neater to me.
* and ? are valid characters for channel names on IRC, and ELIST M gives
no way to distinguish between `LIST #foo-*` that's meant to search for
channels beginning `#foo-` and `LIST #foo-*` that's meant to list one
channel named literally `#foo-*`.
In order to deal with this, we will always assume a name with wildcards
is a mask. If it's also a channel name, that will be listed first.
Further to our implementation of the concept of "secure origins", we can
indicate to services that the client is connected securely, rather than
just that the client is using TLS. For example, connections from the
local host (from the IRCd's perspective) can be considered secure
against eavesdropping.
Allow this to factor into services' decision on whether to allow an SASL
negotiation or not. Atheme currently assumes this means the client is
using TLS, but I have changed that in atheme/atheme@412d50103c
Split oper:wallops right from oper:mass_notice. Update documentation and
examples to grant oper:wallops everywhere oper:mass_notice was granted.
closes#103
* move has_common_channel to s_user.c
* don't remove clients from /accept on NICK when there's a common channel
Co-authored-by: Ed Kellett <e@kellett.im>
We were ending the flood grace period for any channel mode command other
than `MODE #foo [bq]` by means of a hardcoded check. I've moved that to
after we parse the mode string, so we can correctly identify all
requests to change modes and end the grace period on exactly those.
It would have been entirely possible to move the check even further down
and flood_endgrace on only mode commands that *actually* change modes,
but I don't like the idea of making it sensitive to external conditions.
