Call for testing: OpenSSH 8.3
Damien Miller
djm at mindrot.org
Wed May 13 13:11:02 AEST 2020
On Wed, 13 May 2020, Darren Tucker wrote:
> On Wed, May 13, 2020 at 12:30:29PM +1000, Darren Tucker wrote:
> [...]
> > The Makefile doesn't know how to make shared libraries with xlc so it
> > can't build the sk-dummy library. We don't actually use it if you're
> > not building with security key support, I'll see if I can make it skip
> > building it too.
>
> This is a bit ugly but should do it. Can anyone think of a neater way?
No, and this should do the right thing via regress/test-exec,sh as it
skips testing sk-* key types if no sk-dummy.so is found.
ok djm
> diff --git a/Makefile.in b/Makefile.in
> index 7c5ed0bd..c9e4294d 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -635,6 +635,8 @@ SK_DUMMY_OBJS=\
> regress/misc/sk-dummy/fatal.lo \
> ed25519.lo hash.lo ge25519.lo fe25519.lo sc25519.lo verify.lo
>
> +SK_DUMMY_LIBRARY=@SK_DUMMY_LIBRARY@
> +
> .c.lo: Makefile.in config.h
> $(CC) $(CFLAGS_NOPIE) $(PICFLAG) $(CPPFLAGS) -c $< -o $@
>
> @@ -648,7 +650,7 @@ regress-binaries: regress-prep $(LIBCOMPAT) \
> regress/netcat$(EXEEXT) \
> regress/check-perm$(EXEEXT) \
> regress/mkdtemp$(EXEEXT) \
> - regress/misc/sk-dummy/sk-dummy.so
> + $(SK_DUMMY_LIBRARY)
>
> regress-unit-binaries: regress-prep $(REGRESSLIBS) \
> regress/unittests/sshbuf/test_sshbuf$(EXEEXT) \
> diff --git a/configure.ac b/configure.ac
> index 003b235e..46038375 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -3137,6 +3137,10 @@ AC_MSG_RESULT([$enable_pkcs11])
> AC_MSG_CHECKING([whether to enable U2F])
> if test "x$enable_sk" = "xyes" ; then
> AC_DEFINE([ENABLE_SK], [], [Enable for U2F/FIDO support])
> + AC_SUBST(SK_DUMMY_LIBRARY, [regress/misc/sk-dummy/sk-dummy.so])
> +else
> + # Do not try to build sk-dummy library.
> + AC_SUBST(SK_DUMMY_LIBRARY, [""])
> fi
> AC_MSG_RESULT([$enable_sk])
>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>
More information about the openssh-unix-dev
mailing list