* There are two security groups by default: known-users and unknown-users.
See https://www.unrealircd.org/docs/Security-group_block
* New extended ban ~G:securitygroupname, with the typical usage being
MODE #chan +b ~G:unknown-users, which will ban all users from the
channel that are not identified to services and have a reputation
score below 25.
It is highly recommended that services pseudo users all have +o since
there are likely many places where ULines don't bypass a restriction while
opers do. But still, this particular issue has been fixed, it caused
unexplained loss of messages which looked rather mysterious.
Reported by severinmueller in https://bugs.unrealircd.org/view.php?id=5799
The reputation command (IRCOp-only) has been extended to make it
easier to look for potential troublemakers:
* ```REPUTATION Nick``` shows reputation about the nick name
* ```REPUTATION IP``` shows reputation about the IP address
* ```REPUTATION #channel``` lists users in channel with their reputation score
* ```REPUTATION <NN``` lists users with reputation scores below value NN
to the specified number of lines. This defaults to 1000.
This will prevent IRCOps from being flooded off ("Max SendQ exceeded")
if they list all *LINES and there are thousands.
In the newly introduced error message, after too many matches,
we also kindly point out to use filters like '/STATS gline +m *.nl'
Thank you BuildBot.
This means on older OpenSSL's we are not going to have certificate
expiry checks. Those OpenSSL versions were deprecated by the OpenSSL
team itself, so yeah then you will miss out a few things.
by armyn in https://bugs.unrealircd.org/view.php?id=5769.
The default behavior in 5.x is to continue matching:
allow { ip *@*; class clients; maxperip 2; }
allow { ip *@*; password "iwantmore"; class clients; maxperip 10; }
This so users who provide a password get additional rights,
such as a higher maxperip or a different class, etc.
If the user connects without a password then we simply continue
to the next block and use the general block with only 2 maxperip.
However, some people want to use passwords to keep other users out.
That is entirely understandable as it is an 'allow block' after all.
For example:
allow { ip *@*; class clients; maxperip 2; }
allow { ip *@*.nl; password "tehdutch"; class clients; maxperip 2; options { reject-on-auth-failure; } }
In this case anyone without the correct password will be rejected access.
if someone searches explicitly on a nick name and that user exists.
This fixes a bug where doing '/who name a' would return only 1 result
if 'name' exists as a nick, even though multiple people with the
same account 'name' are online and visible to the user, as
reported in https://bugs.unrealircd.org/view.php?id=5761 by Koragg.
Reported by Adanaran in https://bugs.unrealircd.org/view.php?id=5698
Although voiced users normally bypass bans, it is not really logical
for them to bypass filtering of banned words, since that is normally
a policy decission by channel management. So +v will not bypass it.
1) The problem is that this is enforced at the ban layer API. The extban
routines, textban in this case, are not called when the user is voiced,
because voiced users bypass bans. If we would change that in the ban API
then voiced users can also no longer talk through (=bypass) regular +b or
other extended +b such as ~a (account) etc.
2) I figured we would then make +T not use the ban API but the
can_send_to_channel hook instead. However, then you have to do manual
looping through bans and such, it's rather ugly from a coding point of view,
and you risk "missing" things like ~T stacked with ~t.
3) Then I went back to look if the ban API could be changed by having the
textban module set a flag and then the ban api would call that specific
module still for voiced users. While starting on that, unfortunately things
(variables, arguments) cascaded quickly into having to change all kinds of
underlying functions that would break the module API.
4) I then went back to option 2 and implemented it, trying to deal
with all its caveats.
reported by Koragg in https://bugs.unrealircd.org/view.php?id=5757.
This changes the following in the code of who_global():
1) We initialize all the 'marked' users to zero at the beginning,
and remove the previously unmarking in the bottom loop that
shouldn't have anything to do with it. Now there's "no way"
to screw up initialization of marked users.
2) Check for marked users in the bottom loop.
3) Thanks to #1 and #2 we can now easily add simple logic like
not skipping when client==acptr.
4) Similarly, we can remove checks for +i/-i in who_common_channel(),
and as a bonus we will list common channel results altogether
in the WHO result, rather than first +i on common and then at the
very end the remaining -i (which may also be in common channels).
All in all, the code is now more like how I would write it, rather
than the original. It's now harder to screw things up if you change
some visibility or searching logic here or there.
That option specified a Diffie Hellman parameter file. Since
UnrealIRCd 5.0.0 we no longer process this option.
This option has never been documented in the wiki docs.
We prefer and use ECDHE/EECDH with SSL_OP_SINGLE_ECDH_USE since 2015
to provide Forward Secrecy in SSL/TLS. And indeed, by now in 2020,
any properly maintained software uses it and old DH(E) usage has
fallen to less than 1%.
What this patch does is remove the unused code (since Dec 2019) and
show a warning if you have a ::dh config directive, so that at least
you are informed that it is unused/ignored. Since it was undocumented
it probably hardly affects anyone, but still, it is proper to inform.
numbers only. This makes things more logical for end-users.
This fixes https://bugs.unrealircd.org/view.php?id=5746,
bug reported by KindOne.
The same issue was also fixed by previous commit, but still:
it is better to limit things to a narrower range, this so you
don't get different behavior depending on the CPU a server uses.
This adds support for latvian-utf8, estonian-utf8 and lithuanian-utf8
in set::allowed-nickchars. Patch from moseslecce.
Co-authored-by: David Lecce <3292014+davidlecce@users.noreply.github.com>
This should be rare, since modes-on-connect is in the example
configuration file with +ixw since 2003, but still... just in
case someone completely misses the modes-on-connect configuration
item, then make sure that we have a safe and good default.
Bram Matthys