- Win32: Attempt to move to 100% winsock2 (the include, to be precise),
this means includes have to be in a very particular order (!)
- Win32: #define _WIN32_WINNT 0x0501 and force our own inet_ntop/pton,
otherwise you get an ntop runtime error on XP and earlier.
- Win32: Get rid of c-ares includes and library in our tree, and use the
DLL instead of static LIB, just like we do for ssl and zlib.
- Win32: Get rid of TRE lib and includes
- Win32: reorder includes to fix winsock errors with curl
mysterious error 'The specified module could not be found' even though the
file exists. This usually means that it depends on another DLL, but
apparently Microsoft decided not to mention that in the error message.
We now append some small text when such an error happens, saying that it
could be because of a missing dependency. Reported by Phil.
and ZLINE) and 'except tkl' (which can exempt from GLINE, GZLINE, SHUN,
QLINE, GQLINE and SHUN). Reported by Digerati (#0002535).
- Added except tkl::type 'all', which exempts from all TKL types (except
KLINE).
network. You can also specify options like '/REHASH -global -motd' to
rehash only the MOTD/RULES/etc. Just like /REHASH <servername> this is a
NetAdmin-only command. This command is fully backwards compatible with
older UnrealIRCd version in the sense that it will also REHASH old
Unreal's. Suggested by 'P' in #0001522.
'install as service' and 'encrypt SSL certificate', as they are
incompatible (a service cannot ask a user to enter a password).
- Win32 installer: Fixed long outstanding problem with some Vista / Windows 7
installations, which has to do with file permissions of the Unreal3.2
folder. Symptoms were error messages such as:
Unable to create file 'tmp/10D9D743.commands.dll': Permission denied
But also failing to create SSL certificates, nothing being logged, etc.
This is now fixed by setting write access on the Unreal3.2 folder to the
user running the install, unless the user chooses not to use this new
option (it can be unchecked), in which case the user is warned that he
should take care of this himself.
Reported by various persons, special thanks to Bock and goldenwolf for
helping us to track down this issue (#0003943).
- 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).
binki