Any attempt to /OPER by someone who doesn't have one of the listed
usermodes is rejected. This can be used to restrict oper blocks to
registered nicks (+r) or secure clients (SSL, +z).
If this is not set, then SASL is off and not advertised.
If the specified server is not connected, then SASL is off as well.
This prevents unnecessary delay (and the inability for some clients to
get online) when SASL is not in use or when the SASL server is down.
This allows the IRCd to enforce MLOCKs that are set by services, which
eliminates clashes between users setting modes and services enforcing
it's mlock on channels. (#3055)
and ensures that the user does not have any ircop-only user modes after
de-opering. This (only) fixes the just added +I umode case, but could
also prevent future bugs.
now store a string (of max NICKLEN size) as service stamp. See
protoctl.txt and serverprotocol.html in doc/technical for more
information.
Patch from nenotopia (#3966).
- Some small updates to the extended channel mode system: it now has minimal
support for 'local channel modes'. This is really only meant for channel
mode +Z (upcase z), see next.
- Added Channel Mode Z which indicates if a channel is 'secure' or not.
This mode works in conjunction with +z (lower case z).
If +z is set ('only secure users may join'), then the IRCd scans to see
if everyone in the channel is connected through SSL. If so, then the
channel is set +Z as well ('channel is secure').
Whenever an insecure user manages to join, the channel is -Z. And whenever
all insecure users leave, the channel is set +Z.
The 'insecure user being present in a +z channel' can be because:
- An IRCOp joined the channel, and he's not secure
- When servers link together and a user on the other side is not secure
This only happens on net merge (equal time stamp).
On different time stamp, we still kick insecure users on the new side.
- At the time when +z is set, there are insecure users present.
This feature was implemented after a heavy discussion in bug #3720 by fez
and others, and was suggested by Stealth.
Tech note: +Z/-Z is handled locally by each server. Any attempt to
remotely set +Z/-Z (eg: by services) will be ignored.
- As mentioned above, +z can now be set even if any insecure users are
present. Previously, this was not permitted. Now, as soon as the last
non-SSL user leaves, the channel will be set +Z.
- An oper not connected through SSL previously had to /INVITE himself
to a channel and then /JOIN the channel with the key 'override'.
This 'override' key is no longer required, a simple JOIN will suffice.
- Sorted channel modes in /HELPOP ?CHMODES
- Re-enabled 'fishy timestamp' errors in MODE. For some reason this was
commented out, even though the (more annoying and less useful) code in
JOIN was enabled so that did not make a lot of sense. It also now logs to
ircd.log (or whatever you configure). This enables people to easier find
the cause of any timestamp issues (which usually is badly coded services).
commands.so. This module was written to help IRCd maintainers deal
with some sort of ``XPS'' attack in which javascript-initiated HTTP
POST form submissions were able to act as dummy IRC bots. These
simple bots were the cause of much spam. (#3893)
- Add a modules section to the documentation. This was created to put
all documentation specific to the m_post module in one, easy to find
place. The documentation on m_post is likely incomplete, however.
- Added support for "stacked" extbans. Put simply this allows extban combinations
such as ~q:~c:#test to only silence users on #test, for example. This feature
is enabled by default, but can be disabled during ./Config -advanced.
This feature was suggested by Shining Phoenix (#0003193), was then coded
by aquanight for U3.3, and later on backported and partially redone by Syzop.
Module coders:
In an extban ~x:~y:something where we call ~x the 1st, and ~y the 2nd extban:
Since stacked extbans only makes sense where the 1st one is an action
extended ban like ~q/~n/~j, most modules won't have to be changed, as
their extban never gets extended (just like ~c:~q: makes no sense).
However, you may still want to indicate in some cases that the extban your
module introduces also shouldn't be used as 2nd extban.
For example with a textban extban ~T it makes no sense to have ~n:~T.
The module can indicate this by setting EXTBOPT_NOSTACKCHILD in
the ExtbanInfo struct used by ExtbanAdd().
For completeness I note that action modifier extbans are indicated by
EXTBOPT_ACTMODIFIER. However, note that we currently assume all such
extbans use the extban_is_ok_nuh_extban and extban_conv_param_nuh_or_extban
functions. If you don't use these and use EXTBOPT_ACTMODIFIER, then things
will go wrong with regards to stack-counting.
Module coders should also note that stacked extbans are not available if
DISABLE_STACKED_EXTBANS is defined.
- Added extended ban ~R:<nick>, which only matches if <nick> is a registered
user (has identified to services). This is really only useful in ban
exemptions, like: +e ~R:Nick would allow Nick to go through all bans if he
has identified to NickServ. This is often safer than using +e n!u@h.
- Added Extended Invex. This is very much like extended bans, in fact it
supports some of the same flags. Syntax: +I ~character:mask
Currently supported are: ~c (channel), ~r (realname) and ~R (registered).
This can be useful when setting a channel invite only (+i) and then
setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while
still being able to ban users.
Because action modifiers (~q/~n/~j) make no sense here, extended invex
stacking (+I ~a:~b:c) makes no sense either, and is not supported.
Suggested by DanPMK (#0002817), parts based on patch from ohnobinki.
Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by
ExtbanAdd() to indicate that your extban may also be used in +I.
- Invex (+I) now always checks cloaked hosts as well. Just like with bans,
it checks them also when the user is not currently cloaked (eg: did -x, or
is currently using some VHOST).
- Fixed client desynch caused by (un)banning, reported by Sephiroth (#2837).
Nathan Phillip Brink