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.
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.
Tobias Brunner