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).
Currently, the runner images enable break-system-packages globally.
However, this workaround will be removed by the end of March. So
we switch to installing these packages as intended via distro (the
alternative would be to use pipx, at least for tox).
There was an issue with OPENSSL_armcap_P in Android's static build for
OpenSSL 3.1.1+. This was finally fixed with this release (and was also
backported to older versions).
Tobias Brunner