When packaging UnrealIRCd as RPM, 'make install' needs to install
the files into $RPM_BUILD_ROOT rather into '/'. Just changing the
paths via ./Config or ./configure does not fit, because otherwise
UnrealIRCd is finally looking for $RPM_BUILD_ROOT/etc/unrealircd/
rather /etc/unrealircd/. It's fully backwards-compatible, because
normally $DESTDIR is not being passed.
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.
set::history::channel::playback-on-join::lines and
set::history::channel::playback-on-join::time were ignored,
the limit in the +H channel mode was used instead.
Reported by k4be in https://bugs.unrealircd.org/view.php?id=5707
happens if all of the following are true:
1) You use link::outgoing::tls-options (or ssl-options)
2) You do a REHASH -tls (or REHASH -ssl)
3) You do NOT do a regular REHASH
4) You try to link to the server in such a link block (outgoing!)
In other words: the problem may happen if you try to link after
a Let's Encrypt cert renewal, unless there has been a regular
REHASH between that and the outgoing linking attempt.
Reported by k4be and Le_Coyoto in https://bugs.unrealircd.org/view.php?id=5607
depending on the module load order. Reported by k4be.
Changes:
* Websocket hooks:
* Input should be run first
* Output should be run last
* Labeled-response also had various hook priorities wrong
* Pre command should be run near-first
* Post command should be run near-last
* Close connection (does the flush) should be run near-last
* Packet should be run near-last
Previously it didn't display correctly on server notice the TLSv* version on local connection.
Before: TLS_CHACHA20_POLY1305_SHA256
After: TLSv1.3-TLS_CHACHA20_POLY1305_SHA256
Robert Scheck