As mentioned in the previous commit, ASAN does a fine job detecting leaks
during the tests. We just add a single LD-enabled build of the "default"
test here to test the basic functionality.
And we continue to use leak detective in our testing environment to keep
the memory requirements low.
We don't need a separate cache for the "apidoc" test and while the
"dist" test is similar as well, it builds in a different directory,
which means that config.h causes a cache miss for everything but the
configure checks.
The special handling caused a significant diff between builds with and
without LD, which made ccache less effective as we only store the cache
once for the build without LD.
However, despite this change, while it previously was the case that the
LD vs. non-LD builds didn't differ much, that's not the case anymore
nowadays. In particular the --disable-asan option and the BFD-based
backtraces for the native OpenSSL builds (e.g. default or openssl-sys)
cause quite a significant diff. As cache storage is limited, we keep
the current behavior for now. But it might be an option to reduce or
even remove the LD builds in the future as ASAN seems do the job pretty
well and we still use LD in the testing environment.
These are quite a bit faster than on AppVeyor (with ccache about a fifth,
without less than half - and they run concurrently).
We only keep the AppVeyor builds for now to test against those old
OpenSSL versions (1.1.1 and 1.0.2) for which there is still extended
support available. Even simplified like that they still take longer
than the builds on GA.
We are still too close to the limit of 1 hour (at least with the 2019
image and the 2022 image is about the same), so reduce the build time by
not building libimcv natively, which saves about 10 minutes.
Also, only build against OpenSSL 1.0.2 (on the 2017 image) and 1.1.1 (on
the 2019 image) as these are the only versions for which OpenSSL provides
extended support.
The pa_tnc fuzzer does not rely on any plugins and the pb_tnc fuzzer is
a bit special in that it does use code from the tnccs-20 plugin, but that
doesn't actually have to be loaded as such. The fuzzer directly calls
statically linked code from the plugin.
Due to the static build, libcharon will depend on libradius as soon as
eap-radius is enabled even if not actually used. So in order to avoid
breaking the build of fuzz_ike when enabling this in CIFuzz, enable
it now before adding the actual fuzzer.
Closesstrongswan/strongswan#3028
Signed-off-by: Arthur Chan <arthur.chan@adalogics.com>
In particular with the 2019 image, the time required often exceeded the
maximum of 60 minutes. Using lld reduces the runtime quite a bit (it's
still close to the limit, though).
This doesn't work with the old OpenSSL version we use with the 2015
image (that libeay32.lib file just doesn't seem to work), so continue
to use ld (the build on that image is the quickest anyway).
Clean up leak-detective whitelist for newer Botan versions but add
`botan_private_key_load` as `botan_privkey_load*` won't show up anymore
without bfd-backtraces due to inlining if we don't call it directly.
Ref: https://github.com/randombit/botan/discussions/4868
Also remove the --enable-md4 option. We never supported MD4 via wolfSSL,
as it's not available via the hash API we use (would require explicit
MD4-specific functions and structures).
The Homebrew formula has been using OpenSSL 3 for a while. The eap-peap
and pkcs11 plugins also have been enabled in the formula. The dhcp plugin
is enabled to test the port (the farp plugin was already enabled since
its port to FreeBSD/macOS). The drbg plugin is enabled to run the ML-KEM
test vectors.
We keep MD5 enabled for now as we need it for TLS 1.0/1.1. Once we
remove that we can reconsider (although, it's also needed for EAP-MD5
and since MD4 is disabled as well, which means EAP-MSCHAPv2 won't
be available, we'd be left with only EAP-GTC for simple username/password
authentication, which nobody else supports).
The plugin was apparently broken for years because it uses functions that
don't exist anymore. It was quite limited anyway, so it was never really
used in OpenWrt to begin with (instead they generate configs in a custom
init script).
A recent gettext release (0.25 via Homebrew) installs the M4 macros in a
different location (<prefix>/share/gettext/m4 instead of
<prefix>/share/aclocal). According to the commit messages to avoid "bad
interactions between autoreconf and autopoint". Since we only depend
on gettext for that macro and this move makes it complicated, we can also
just integrate the macro from gnulib directly (which gettext 0.18+ relies
on anyway).
Tobias Brunner