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>
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 follows FIPS 203 relatively closely but takes some ideas from the
reference implementation. In particular, how to avoid potential
side-channels via direct C division/modulo operations. However, it just
uses Barrett reduction (no Montgomery reduction) and no negative
coefficients to avoid number format conversions and keep the
implementation clearer.
These allow, for instance, a vici client on a host to communicate with
an IKE daemon running in a VM.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
This also refactors the BPF handling so it can be shared between the
dhcp and farp plugins. The latter is adapted accordingly.
Closesstrongswan/strongswan#2047
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
The openxpki plugin directly access the certificates table in
the OpenXPKI's MariaDB in order to retrieve the status of an
issued X.509 certificate based on its serial number.
The cert-enroll script handles the initial enrollment of an X.509
host certificate with a PKI server via the EST or SCEP protocols.
Run as a systemd timer or via a crontab entry the script daily
checks the expiration date of the host certificate. When a given
deadline is reached, the host certificate is automatically renewed
via EST or SCEP re-enrollment based on the possession of the old
private key and the matching certificate.
This commit fixes auto detection of in6_pktinfo.
When negotiating an IPv6 IKE session charon reported an error
"Jun 30 16:42:49 03[NET] error reading IP header"
The cause of error was missing in6_pktinfo declaration, which is
auto detected. This auto detection may fail with an error depending
on compiler flags:
configure:19850: checking for in6_pktinfo
configure:19870: gcc -c -g -O0 -Wall -Wno-format -Wno-format-security
-Wno-pointer-sign -Werror -Wfatal-errors -Wno-error=stringop-truncation
conftest.c >&5
conftest.c: In function 'main':
conftest.c:73:11: error: 'pi.ipi6_ifindex' is used uninitialized in this
function [-Werror=uninitialized]
73 | if (pi.ipi6_ifindex)
| ~~^~~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
Signed-off-by: Antony Antony <antony.antony@secunet.com>
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.
