1. it links with ${SSL_LIBRARIES}, in WolfSSL builds it's a static
library, so when a plugin is loaded there will be two copies of
wolfssl in the same address space. It breaks odr (at least).
2. Plugin can linked with OpenSSL and the server with WolfSSL or
vice versa. It might load, but then we'll have both WolfSSL and
OpenSSL at the same time. Kind of risky.
Fix: link the plugin statically into the server if it's a WolfSSL build
adjust tests to work with static and dynamic parsec
here MSAN complains that
==218853==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f84a77c60a3 in _gnutls_rnd_init /tmp/msan/lib/random.c:69:6
#1 0x7f84a77c60a3 in gnutls_rnd /tmp/msan/lib/random.c:168:6
but the line lib/random.c:69 in gnutls-3.7.1 is
69 if (unlikely(!rnd_initialized)) {
and rnd_initialized is declared as
40 static _Thread_local unsigned rnd_initialized = 0;
which apparently MSAN isn't happy with
PARSEC: Password Authentication using Response Signed with Elliptic Curve
new authentication plugin that uses salted passwords,
key derivation, extensible password storage format,
and both server- and client-side scrambles.
It signs the response with ed25519, but it uses stock
unmodified ed25519 as provided by OpenSSL/WolfSSL/GnuTLS.
Edited by: Sergei Golubchik
in bintars the server is linked with wolfssl, while the connector
is linked with gnutls. Thus client_ed25519.so gets gnutls
dependency, unresolved symbols and it cannot be loaded into the
server and gnutls symbols aren't present there.
linking the plugin statically with gnutls fixes that and the test passes.
but when such a plugin is loaded into the client, the client gets
two copies of gnutls - they conflict and ssl doesn't work at all.
let's detect this and disable the test for now.
realloc can't be done for mysql->passwd. There's also no pretty way to
pass the ext-salt into hash_password, so let's use thread_local instead.
For GCC < 4.9 (SLES 12, CentOS 7), which don't support _Thread_local,
pk will be recalculated instead
