Because libcrypto and libssl are measured, we need a new group for Debian
versions with OpenSSL 3 (I've rather added a suffix to the old group as
that could eventually get removed, although we might need a 3.1 variant
in the future - maybe we should measure some other files?).
OOM-killer is now already triggered with `import daemon`, so set the
limit before that. Also some PEP8 fixes (including an exclusion for
the above fix as that causes imports to not be at the beginning of the
file).
Without this, Git refuses to operate on the build dirs that are mounted
with weird ownership. When running as root in the chroot, Git checks
SUDO_UID, which won't match.
This is necessary because TKM can't read PKCS#8 files and in some
scenarios we don't have the pkcs8 plugin loaded that would be required
to read/decrypt the non-traditional files.
The wrapper called the command twice for any unit but "strongswan" and
it didn't return the correct exit code. This was noticed when an
if-updown script tried to check if systemd-resolved is active and always
succeeded, which caused failing attempts to configure it.
But now that the return code is correct, trying to enable bind9 won't
fail silently anymore if the unit doesn't exist (similar on older systems
for named), so this is adapted.
With Debian bookworm, the PQC KE sntrup761x25519-sha512 is negotiated, by
default. This increases the overhead significantly, in particular, the
size of the KE message, which wouldn't get through IPsec tunnels without
MSS clamping.
Since 17fd304e60df ("resolve: Don't install individual servers via
resolvconf"), DNS servers were sorted if getting installed via resolvconf.
In some setups the order might be important (even though relying on it
isn't a good idea in general as stub resolvers are free to use all of
the servers as they please).
The previous code was problematic if a certificate request for a known
but unrelated CA was received and the local trust chain was incomplete.
Due to the received anchor, the incomplete trust chain was dismissed and
any intermediate CA certificates were, therefore, not sent to the peer.
This new approach doesn't dismiss an incomplete trust chain, but prefers
one that can be resolved to a received anchor. If no such chain is found,
the first one is used.
This adds support for sending/receiving ESP packets without UDP
encapsulation to libipsec and kernel-libipsec. Only Linux is currently
supported and the feature is disabled by default.
This is currently only supported on Linux and with the appropriate
permissions.
Since it's experimental, it's disabled by default.
The log messages for each sent and received ESP message are logged in NET
like the ones in the socket-default plugin for UDP-encapsulated messages.
Currently just based on the reqid. An acquire for the same reqid is
triggered at most every 10 seconds (gets ignored in trap_manager_t if
the SA is still getting established).
Entries are only cleaned up if an SA is eventually installed (similar to
the allocated SPIs). Should that ever be a problem, we could probably
schedule a job that regularly flushes old entries.
The calculation of the timeout is also shared now and the total
timeout in seconds is corrected in case retransmit_base is <= 1.
This could make it easier in the future to apply different retransmission
settings to messages/exchanges.
When using OpenXPKI, the subject DN in the renewal request has to match
the previous DN exactly. However, because OpenXPKI may add a bunch of
DC/O RDNs to subjects of issued certificates, running --scep with the
same --dn that was used for the original request won't work (results in
a "Client error / malformed request badRequest" error even after enabling
`renewal_via_pkcs_req`). This simplifies renewals as --dn can just be
omitted and extracted from the original certificate to avoid this issue.
References strongswan/strongswan#1689
This fixes the build with DEBUG_LEVEL < 4, which was broken when building
from the repository since --enable-warnings was made the default.
Although, most issues only occurred with the level reduced to 0/-1. And
while removing debug statements at compile time completely is probably
not useful in production, there might be use cases in certain benchmarking
scenarios. Also, with the recent changes to the controller there should
only rarely be a listener registered at a higher log level so the overhead
for those higher-level DBG statements is minimal.
Anyway, reducing the log level at compile time is a documented feature and
at least DEBUG_LEVEL=3 could be useful to prevent leaking sensitive
information via logs from the outset. So we should make sure compilation
doesn't fail.
