Also enables the `kdf` plugin automatically if building against an older
version of OpenSSL.
Closesstrongswan/strongswan#2602
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
On Ubuntu 24.04, llvm-symbolizer-18, which is used to resolve symbols
in backtraces, links libcurl.so.4 for some reason. And that in turn
requires SRP. If our custom build doesn't provide it, we get stuff
like this
/usr/bin/llvm-symbolizer-18: symbol lookup error: /lib/x86_64-linux-gnu/libcurl.so.4: undefined symbol: SSL_CTX_set_srp_password, version OPENSSL_3.0.0
and the symbols are not resolved and can't be whitelisted.
This also makes sure ASan is actually disabled if our own leak-detective
is used.
Directly calling setup.py is deprecated (apparently has been for a while,
but now we get large warnings). Direct installation is also discouraged.
So this removes that option. The built wheel (the old egg format is not
used/built anymore) can be installed manually in a venv or the like.
This registers support for the ML_KEM_{512,768,1024} key exchange
algorithms in the `openssl` plugin when built using AWS-LC as the
libcrypto. To do this, we introduce the `openssl_kem` source files
which implement the key exchange algorithm using the Key Encapsulation
Mechanism (KEM) API. Future KEM algorithms can be implemented
generically using this interface by substituting the appropriate NIDs.
It also supports both seeded (via DRBG) and unseeded modes depending
on the user's requirements for KATs or entropy sources.
It should be noted that this does not add support for KEM algorithms
within upstream OpenSSL and is API incompatible. Future work will need
to condition out the incompatibilities as-appropriate. However, the
high-level logic should be the same for all KEMs and KEM APIs.
References strongswan/strongswan#2228Closesstrongswan/strongswan#2490
AWS-LC is an OpenSSL derivative which can be used with the openssl plugin.
This adds a CI job that resembles the openssl-3 test case. It downloads
the source tarball for an AWS-LC release, builds that source using
CMake/Ninja, and then builds/tests strongSwan using the same technique
used by openssl-3.
References strongswan/strongswan#1907Closesstrongswan/strongswan#2151
The gperf version that's already available on the system generates
function declarations with K&R syntax (separate arguments) for which newer
compilers produce a warning as C23 doesn't support that syntax anymore.
The all-zero Ed25519 public key is rejected by botan_pubkey_check_key()
when the key is loaded.
Note that Botan 3 requires GCC 11 or CLANG 14, i.e. can't easily be built
on Debian bullseye or Ubuntu 20.04.
The thread-local storage function gets flagged via various botan FFI
functions when using Botan 3, whitelist that instead of all of them.
The `--enable-heapmath` configure option has been deprecated. As
already described in eae30af029b1 ("Use wolfSSL 5.4.0 for tests"), the
alternative is to configure `--with-max-rsa-bits=8192` instead in order
to test the modp6144 and modp8192 DH groups.
The Ubuntu 18.04 image is deprecated and builds will start to fail
temporarily during four 24 hour periods from now until the final
deprecation on April 1st. So better remove these runs now.
With newer OpenSSL builds, the DLL files contain parts of the version
number and the architecture in their name, e.g. for OpenSSL 1.1.1 the
DLL for libcrypto is called libcrypto-1_1-x64.dll. So referencing that
directly could be kinda tricky. And by using `-lcrypto` we therefore
didn't link those DLLs but the OpenSSL version installed by msys2.
Since the latter ships OpenSSL 3 since January and the VS 2019 image
was updated recently, our builds broke as we used the headers from
the 1.1.1 installation but then tried to link OpenSSL 3.
Luckily, in the lib/ directory of the OpenSSL installation, there is a
libcrypto.lib file, which is an import library (containing the symbols
and a reference to the DLL). We can use that to link the right library
via `-lcrypto`.
With the old OpenSSL 1.0.2 build on the VS 2015 image, there is also
such a .lib file but it seems the linker is too old or otherwise incapable
of finding the DLL. But since the DLL is just called libeay32.dll there,
we use that directly and don't reference the lib/ dir.
Also removed a superfluous AC_MSG_RESULT() if libeay32 isn't found.
