A wrong variable is used (route instead of best), so much that the
returned interface belongs to the last seen route instead of the best
choice route.
get_route() may therefore return mismatching interface and gateway.
Fixes: 66e9165bc6 ("kernel-netlink: Return outbound interface in get_nexthop()")
Signed-off-by: Christophe Gouault <[email protected]>
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.
This was added a few years ago because pki --signcrl once encoded serials
incorrectly as eight byte blobs. But still ensure we have can handle
overflows in case the serial is encoded incorrectly without zero-prefix.
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.
We parse aes*gmac as encryption algorithm, which we have to map to an
integrity algorithm. We also make sure we remove all other encryption
algorithms and ensure there is an integrity algorithm.
If a responder is natted it will usually be a static NAT (unless it's a
mediated connection) in which case adding these notifies makes not much
sense (if the initiator's NAT mapping had changed the responder wouldn't
be able to reach it anyway). It's also problematic as some clients refuse
to respond to DPDs if they contain such notifies.
Fixes#2126.
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.
If we silently delete the IKE_SA the other peer might still use it even
if only to send DPDs. If we don't answer to DPDs that might result in the
deletion of the new IKE_SA too.
This is the minimum size an IPv6 implementation must support. This makes
it the default for IPv4 too, which presumably is also generally routable
(otherwise, setting this to 0 falls back to the minimum of 576 for IPv4).
The maximum would not get set correctly when a logger is removed and the
first remaining logger in the list (the one with the highest log level) does
e.g. only implement vlog() while there are other loggers that implement log().
This would result in only max_vlevel getting set correctly while max_level
would incorrectly get set to -1 so that log() would not get called for any
of the loggers anymore.
References #574.
The kernel will apply the mask to the mark on the packet and then
compare it to the configured mark. So to match only unmarked packets we
have to be able to set 0/0xffffffff.
Tobias Brunner