Unfortunately, we can't just add the generated C file to the sources in
Makefile.am as the linker would remove that object file when it notices
that no symbol in it is ever referenced. So we include it in the file
that contains the library initialization, which will definitely be
referenced by the executable.
This allows building an almost stand-alone static version of e.g. charon
when building with `--enable-monolithic --enable-static --disable-shared`
(without `--disable-shared` libtool will only build a version that links
the libraries dynamically). External libraries (e.g. gmp or openssl) are
not linked statically this way, though.
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.
While this API is documented as legacy (and there is a sysctl option to
disable it) the documentation also mentions that it will probably stay
enabled by default due to compatibility issues with existing applications.
With the previous approach only 255 devices could be opened then the
daemon had to be restarted.
Fixes#2313.
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