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

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 [off-list ref]:

quoted

On Tue, Jul 10, 2018 at 10:52:31AM +0200, Henning Schild wrote:

quoted

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.

quoted

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