This strangely never caused any noticeable issues, but was the reason for
build failures in certain test cases (mostly BLISS) due to missing plugin
features when built with specific options on Travis (was not reproducible
locally).
These options disable validation as such, e.g. even from cached CRLs, not
only the fetching. Also made the plugin's validate() implementation a
no-op if both options are disabled.
So far every "newer" CRL (higher serial or by date) replaced an existing
"older" CRL. This meant that delta CRLs replaced an existing base CRL
and that base CRLs weren't added if a delta CRL was already stored. So
the base had to be re-fetched every time after a delta CRL was added.
With this change one delta CRL to the latest base may be stored. A newer
delta CRL will replace an existing delta CRL (but not its base, older
base CRLs are removed, though). And a newer base will replace the existing
base and optional delta CRL.
BoringSSL only supports a limited list of (hard-coded) algorithms via
EVP_get_cipherbyname(), which does not include AES-GCM. While BoringSSL
deprecated these functions they are also supported by OpenSSL (in BoringSSL
a completely new interface for AEADs was added, which OpenSSL currently does
not support).
In case of an empty LDAP result during a CRL fetch (for example, due to
a wrong filter attribute in the LDAP URI, or invalid LDAP configuration),
the call to ldap_result2error() with NULL value for "entry" lead to
a crash.
Closesstrongswan/strongswan#52.
charon-nm fails to find the private key when its CKA_ID doesn't match the
subjectKeyIdentifier of the X.509 certificate. In such cases, the private
key builder now falls back to enumerating all the certificates, looking for
one that matches the supplied subjectKeyIdentifier. It then uses the CKA_ID
of that certificate to find the corresponding private key.
It effectively means that PKCS#11 tokens where the only identifier to relate
the certificate, the public key, and the private key is the CKA_ID are now
supported by charon-nm.
Fixes#490.
In case an external thread calls into our code and logs messages, a thread
object is allocated that will never be released. Even if we try to clean
up the object via thread value destructor there is no guarantee that the
thread actually terminates before we check for leaks, which seems to be the
case for the Ada Tasking threads.
Some of these are pretty broad, so maybe an alternative option is to
not use the soup plugin in the openssl-ikev2/rw-suite-b* scenarios. But
the plugin is not tested anywhere else so lets go with this for now.
Martin Willi