Only for ~/unrealircd/lib/ we had this ommision, and for ~/unrealircd itself.
I doubt this means a change for users, as all subdirs were already 0700
so then tightening of ~/unrealircd is not very important.
And only upsides... making things safer..
We previously upgraded to 1.0.21 and then downgraded to 1.0.20.
Benefit of 1.0.22 is that they also claim to have fixed a warning flood
i am getting with clang 22.
Version 1.0.21 which we shipped with 6.2.3 has this bug, reported
by PhotoJim at https://bugs.unrealircd.org/view.php?id=6615.
And yes, libsodium also has this weird -stable thing, which does
have the fix, but that's basically just a snapshot of their git
version, it's a .tar.gz that gets updated every X time and it does
not have a GPG signature, while I have the policy nowadays to
verify GPG signatures for libraries we ship. So I am option to just
downgrade a version, for now, which is fine since we shipped with
1.0.20 for quite some time until recently.
geoip_classic and geoip_mmdb in modules.default.conf with Conditional
Config, a dynamic loadmodule line, and auto-updates.
Somewhere in a later version, probably 6.2.5, we will default to mmdb
for all cases.
This is mainly due to licensing. The libmaxminddb library uses the
Apache license, which meant if we would compile it in by default it
would effectively transform our "GPLv2 or later" to "GPLv3 or later".
Our implementation is ISC licensed, so we can include and enable it
by default and keep things at "GPLv2 or later". This is also why we
used geoip_classic in the first place as default and compiled in,
and not the mmdb variant.
The mmdb.c is based on the specification, using the Go implementation
as a reference during development (ISC licensed), initially implemented
with the help of Claude Opus 4.6. After that substantial changes were
made to make it match UnrealIRCd's style and to make things less error
prone: C style changes, allocation and zero termination of strings in
the library, auto-NULL in variadic functions so the caller cannot
forget NULL there (similar to our unreal_log/do_unreal_log), using
enums as the return type instead of int (similar to curl), adding
doxygen docs, etc.
This also means the old mmdb library dependency has been dropped,
including from configure/autoconf.
At the moment we still use the geoip classic library by default,
including those DB files. The idea is we will switch over sometime
later after this current new MMDB stuff has received more testing.
This also makes us more flexible, since .mmdb files have become the
de-facto standard for pretty much all geoip vendors.
Previously we didn't and that means that if any shipped lib was used,
without hardening, this would cause non-CET libraries to silently disable
CET for the entire process, and partial RELRO on the libs means the
full RELRO in UnrealIRCd is much less useful.
Actually, system libs on Debian/Ubuntu don't even have full RELRO atm,
but hey, we try to do better, also.. some other OS/distro might
have it on and who knows Debian/Ubuntu change their mind later..
as useful as initially thought. I thought kernel hardening checker
was in favor of it, and they were, but they dropped it in Oct 2023.
(i added it 2-3hrs ago in 0ab1221a38)
This zeroes out variables that COULD be accessed before being set
(so to prevent access to unitialized variables). We are generally
very careful about this in our code, but in 3rd party modules this
is less the case. And still useful in case we ourselves screw up.
Is defense in depth to make ROP harder. In general this is reported to
have a performance impact of 2% worst-case. Linux kernel reports 1%.
Should be closer to 0% for us, or that 1% if i am wrong.
https://lwn.net/Articles/870045/ has some background on this.
This should help gcc/clang with finding more OOB write bugs.
It does mean that 3rd party modules can no longer use the something like:
struct { char name[1]; }
and then alloc(sizeof(struct) + length of name)
instead the struct element needs to be name[];
...and they would need to alloc(sizeof(struct) + length of name + 1)
No 3rd party modules in unrealircd-contrib use this so.. hopefully fine.
Previously, due to HARDEN_LDFLAGS missing in MODULEFLAGS we were
only partial RELRO instead of full RELRO. This is a defense-in-
depth measure but is good to have and the ommission was unintended.
(both AddressSanitizer and UndefinedBehaviorSanitizer)
This previously helped finding 8c26cec5fc
Also update the ./Config text a bit, eg about ASan not running OK on FreeBSD,
which only affects <14.2 as per https://bugs.unrealircd.org/view.php?id=6470#c23412
We don't set it in UnrealIRCd at the moment, so this is just to override
the OpenSSL defaults at the moment. It is good to have this exposed, in
case some vulnerability is discovered or you need some flexibility in
tweaking this.
Without this on some new compilers this raises a warning (or error with -Werror):
const char hexchars[16] = "0123456789abcdef";
The alternative is to add __attribute__((nonstring)) at the various places
that need it. But 1) that requires various ifdefs to support old compilers, and
2) This doesn't catch anything meaningful in our code anyway and the odds of
it doing so seem slim.
Previously this was like:
TLSv1.3-TLS_CHACHA20_POLY1305_SHA256
It is now changed to be like:
TLSv1.3/X25519/TLS_CHACHA20_POLY1305_SHA256
So:
* Changed from '-' to '/' because sometimes the cipher(suite)
contains a hyphen (TLSv1.2 and earlier)
* Show the key exchange "group" in the middle, such as X25519
for the usual non-PQC case and X25519MLKEM768 for hybrid group
with PQC.
* The group is shown in OpenSSL 3.0.0+ (and obviously you need
OpenSSL 3.5.0 to ever see X25519MLKEM768 there, but that is
something different)
Bram Matthys