On Wed, Jul 11, 2018 at 12:38:24PM +0200, Henning Schild wrote:
> Am Tue, 10 Jul 2018 13:09:01 -0400
> schrieb Jeff King <p...@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 commit...@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.Yeah, I agree that would be good. If gpgsm does anything like what gpg does, it will require the use of /dev/random, which means this will definitely be slow on build servers and other noninteractive systems. We have this problem at $DAYJOB when automating generation of gpg keys. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
