maximum number of conversations a user can have with other users at the
same time. Until now this was hardcoded at limiting /MSG and /INVITE to
20 different users in a 15 second period. The new default is 10 users,
which serves as a protection measure against spambots.
See https://www.unrealircd.org/docs/Set_block#maxcc for more details.
preferring AES-256 over AES-128 (in contrast to the Mozilla "intermediate"
profile which prefers AES-128). Again, this only affects non-PFS cases, as
all modern clients with PFS already had CHACHA20 and AES-256 negotiated.
The portion of non-PFS clients should only be few percent, if any.
I was actually considering removing non-PFS ciphersuites but it seems a bit
early to do so, at least not without more research on affected clients.
Since OpenSSL decided not to use the regular ciphers but make this a
separate option, we now make this a separate option as well.
So there is ::ciphers for <=TLSv1.2 and ::ciphersuites for TLSv1.3
More documentation will follow.
Patch from 'i' in https://bugs.unrealircd.org/view.php?id=5149
the following remarks:
* We only set these curves if SSL_CTX_set1_curves_list() is available
(OpenSSL 1.0.2 or later, LibreSSL 2.5.1 or later)
* The X25519 curve is only added if it is available (OpenSSL 1.1.0+)
would allow you to use -f even if the IRCd is suid or sgid.
This is not anything we or you ever want to permit since this is
a major security problem. This setting is now gone. I doubt
anyone used it.
This so upcoming UnrealIRCd version will work with TLSv1.3 whenever it
becomes an official standard and is included in OpenSSL/LibreSSL.
(Verified to work with openssl git master branch)
value needs to be much higher than the number of clients the IRCd
should be able to hold. The new value is 10k which should allow
at least 1-2k clients.
code clutter and was broken anyway (especially CHROOTDIR)...
For a CHROOTDIR replacement we suggest using AppArmor, SELinux, FreeBSD jails, ..
For a IRC_USER/IRC_GROUP replacement you can use start-stop-daemon or similar.
This resulted in 5-10 changes in the existing code where parameters were off.
Hopefully I didn't make too many mistakes when writing the hook prototypes as it was a tedious job.
An (unintentional) benefit of this new system is that you can see the hook prototypes in include/modules.h like:
/* Hook prototypes */
int hooktype_local_quit(aClient *sptr, char *comment);
....
Though, the wiki is likely a better place: https://www.unrealircd.org/docs/Dev:Hook_API
2) Call DNS routines more often, not just once per second.
2) Slightly lower the DNS timeout, max 2500 + 5000 = 7500ms now. Previously was 3000 + 6000 = 9000ms.
* add general matching framework (aMatch type, unreal_match_xxx functions)
* change spamfilter { } block syntax
* add support for simple wildcard matching (non-regex, just '?' and '*')
This is the initial commit so the new lib is not in yet, 'regex' is not
functional (but 'posix' and 'simple' are working), linking has not been
fully tested and no warnings are printed yet. IOTW: work in progress!
- Disable USE_POLL on Windows, since it doesn't work with XP and has
no advantage anyway. Reported by nenolod (#4129).
- Various updates to makefile.win32 and .iss file, found during
building new versions of zlib, openssl, and curl.
In the IRCd world correct time is very important. This means that time
should be correct when the IRCd is booted, either by running ntpd/ntpdate
on the system or some other synchronization software, or by using the
built-in timesync feature.
Whenever the clock is adjusted for more than a few seconds AFTER the IRCd
has booted, it can lead to dangerous effects ranging from unfair
timestamps
for nicks and channels (and hence the possibility to takeover channels),
to even completely stalling the IRCd (negative timeshift) or making it so
nobody can connect anymore due to throttling (positive timeshift).
We now try to 'fix' the worst effects such as the IRCd freeze and
throttling. This does not fix the whole problem, so I've added some big
warnings when the clock is adjusted, including an annoying one every 5
minutes if the clock was set backwards, until the time is OK again
(catches up with the original time).
This fixes#0003230 reported by Stealth, and #0002521 reported by durrie.
each time it executes, how LONG it takes to execute. When a certain
threshold
is reached the IRCd will warn or even remove the spamfilter. This will
prevent
a spamfilter (regex) from slowing down the IRCd too much, though it's
still not
a guarantee that it will never go to a halt (eg: in case it takes several
minutes to execute a regex or loops forever).
Warning can be configured via set::spamfilter::slowdetect-warn (default:
250 milliseconds) and automatic deletion of spamfilters if it takes too
long is set through set::spamfilter::slowdetect-fatal (default: 500 ms).
NOTE: slow spamfilter detection is currently not available on Windows.
NOTE 2: to disable slow detection you can set the warn and fatal settings
to 0 (zero). OR to really disable all code, remove SPAMFILTER_DETECTSLOW
from include/config.h and recompile.
now set a ban on *!*@*h.com and then later add one on *!*@*blah.com
without
any trouble. Previously the second one was rejected due to the former
already matching it. To change it back edit the include/config.h setting
SOCALLEDSMARTBANNING.
defines IRC_USER, IRC_GROUP which is a string specifiying what user name/
group name that should be changed into, instead of a hardcoded gid/uid.
This should make it easier for packaged binary releases to work (even
though this probably means Debian will take us in, ick .. Can't we pull
a new fight with debian-legal again?)
- #0003363 patched by adrianp, changing IRC_UID and IRC_GID into
defines IRC_USER, IRC_GROUP which is a string specifiying what user name/
group name that should be changed into, instead of a hardcoded gid/uid.
This should make it easier for packaged binary releases to work (even
though this probably means Debian will take us in, ick .. Can't we pull
a new fight with debian-legal again?)
Bram Matthys