Re: [PATCH v2 9/9] gpg-interface t: extend the existing GPG tests with GPGSM

> Am Tue, 10 Jul 2018 13:09:01 -0400
> schrieb Jeff King <peff@peff.net>:
> 
> > On Tue, Jul 10, 2018 at 10:52:31AM +0200, Henning Schild wrote:
> > 
> > > diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
> > > index a5d3b2cba..9dcb4e990 100755
> > > --- a/t/lib-gpg.sh
> > > +++ b/t/lib-gpg.sh
> > > @@ -38,7 +38,14 @@ then
> > >  			"$TEST_DIRECTORY"/lib-gpg/ownertrust &&
> > >  		gpg --homedir "${GNUPGHOME}" </dev/null >/dev/null
> > > 2>&1 \ --sign -u committer@example.com &&
> > > -		test_set_prereq GPG
> > > +		test_set_prereq GPG &&
> > > +		echo | gpgsm --homedir "${GNUPGHOME}" -o
> > > "$TEST_DIRECTORY"/lib-gpg/gpgsm.crt.user --passphrase-fd 0
> > > --pinentry-mode loopback --generate-key --batch
> > > "$TEST_DIRECTORY"/lib-gpg/gpgsm-gen-key.in &&  
> > 
> > Is this --generate-key going to require high-quality entropy? That
> > could slow the test suite down (and maybe even stall it quite a bit
> > on servers doing automated CI).
> 
> Yes, i also saw that getting "stuck" on one machine. But i blamed an
> experimental kernel.
> 
> > Can we save a dummy generated key and just import it? That's what we
> > do for the regular gpg case.
> 
> I will look into storing a binary and leaving notes how it was
> generated, just like regular gpg does. The reason i did not do that in
> the first place is that x509 certs have a validity and we introduce
> time into the picture. But i will see if i can generate epoch->infinity
> to get the host clock or just the future out of the picture.