Previously sk-dummy.so used libc's (or compat's) SHA256 since it may be
built without OpenSSL. In many cases, however, including both libc's
and OpenSSL's headers together caused conflicting definitions.
We tried working around this (on OpenSSL <1.1 you could define
OPENSSL_NO_SHA, NetBSD had USE_LIBC_SHA2, various #define hacks) with
varying levels of success. Since OpenSSL >=1.1 removed OPENSSL_NO_SHA
and including most OpenSSL headers would bring sha.h in, even if it
wasn't used directly this was a constant hassle.
Admit defeat and use OpenSSL's SHA256 unless we aren't using OpenSSL at
all. ok djm@
Since this test doesn't use OpenSSL's SHA2 and may cause conflicts we
don't want to include it, but OPENSSL_NO_SHA was removed beginning in
OpenSSL's 1.1 series.
We don't use SHA256 from OpenSSL in the sk-dummy module and the
definitions can conflict with system sha2.h (eg on NetBSD) so define
OPENSSL_NO_SHA so we don't attempt to redefine them.
also, make it pull prototypes directly from sk-api.c and #error
if the expected version changes. This will make any future regress
test breakage because of SK API changes much more apparent
OpenBSD-Regress-ID: 79b07055de4feb988e31da71a89051ad5969829d
and PIN prompting in the dummy middleware that we use for the tests. Should
fix breakage spotted by dtucker@
OpenBSD-Regress-ID: 379cf9eabfea57aaf7f3f59dafde59889566c484
markus@
This will allow us to test U2F/FIDO2 support in OpenSSH without
requiring real hardware.
ok markus@
OpenBSD-Regress-ID: 88b309464b8850c320cf7513f26d97ee1fdf9aae
Darren Tucker
dtucker@openbsd.org
Damien Miller
djm@openbsd.org