For salt lengths other than 20 this requires 0bd8137e68c2 ("cipher:
Add option to specify salt length for PSS verification."), which was
included in libgcrypt 1.7.0 (for Ubuntu requires 17.04). As that makes
it pretty much useless for us (SHA-1 is a MUST NOT), we require that version
to even provide the feature.
This is not ideal as the call to C_Finalize() should be the last one via
the PKCS#11 API. Since the order in which jobs are canceled is undefined
we can't be sure there is no other thread still using the library (it could
even be the canceled job that still handles a previous slot event).
According to PKCS#11 the behavior of C_Finalize() is undefined while other
threads still make calls over the API.
However, canceling the thread, as done previously, could also be problematic
as PKCS#11 libraries could hold locks while in the C_WaitForSlotEvent() call,
which might not get released properly when the thread is just canceled,
and which then might cause later calls to other API functions to block.
Fixes#2437.
The order of arguments in X509_CRL_get0_signature() is not the same as that
of X509_get0_signature().
Fixes: 989ba4b6cd ("openssl: Update CRL API to OpenSSL 1.1.0")
They now match the dh_constructor_t signature. This is a follow up for
the changes merged with b668bf3f9e and should fix use of MODP_CUSTOM on
Apple's ARM64 platform.
By definition, m must be <= n-1, we didn't enforce that and because
mpz_export() returns NULL if the passed value is zero a crash could have
been triggered with m == n.
Fixes CVE-2017-11185.
Unlike mpz_powm() its secure replacement mpz_powm_sec() has the additional
requirement that the exponent must be > 0 and the modulus has to be odd.
Otherwise, it will crash with a floating-point exception.
Fixes: CVE-2017-9022
Fixes: 3e35a6e7a1 ("Use side-channel secured mpz_powm_sec of libgmp 5, if available")
Enabled when building monolithically and statically.
This should allow us to work around the -whole-archive issue with
libtool. If the libraries register the plugin constructors they provide
they reference the constructors and will therefore prevent the linker from
removing these seemingly unused symbols from the final executable.
For use cases where dlsym() can be used, e.g. because the static libraries
are manually linked with -whole-archive (Linux) or -force-load (Apple),
this can be disabled by passing ss_cv_static_plugin_constructors=no to
the configure script.
Rename the crypt() method to avoid conflict with POSIX crypt(). Fixes the
following build failure with musl libc:
In file included from ../../../../src/libstrongswan/utils/utils.h:53:0,
from ../../../../src/libstrongswan/library.h:101,
from af_alg_ops.h:24,
from af_alg_ops.c:16:
af_alg_ops.c:110:22: error: conflicting types for 'crypt'
METHOD(af_alg_ops_t, crypt, bool,
^
../../../../src/libstrongswan/utils/utils/object.h:99:13: note: in definition of macro 'METHOD'
static ret name(union {iface *_public; this;} \
^
In file included from af_alg_ops.c:18:0:
.../host/usr/x86_64-buildroot-linux-musl/sysroot/usr/include/unistd.h:144:7: note: previous declaration of 'crypt' was here
char *crypt(const char *, const char *);
^
Closesstrongswan/strongswan#72.
While RFC 3779 says we SHOULD mark it is critical, this has severe side effects
in practice. The addrblock extension is not widely used nor implemented, and
only a few applications can handle this extension. By marking it critical,
none of these applications can make use of such certificates where included
addrblocks do not matter, such as TLS/HTTPS.
If an application wants to make use of addrblocks, that is usually an explicit
decision. Then the very same application obviously can handle addrblocks, and
there is no need for the extension to be critical. In other words, for local
policy checks it is a local matter to handle the extension, hence making it
critical is usually not of much help.
Tobias Brunner