Re: t7510-signed-commit.sh hangs on old gpg, regression in 1bfb57f642d (was: [PATCH v8 9/9] ssh signing: test that gpg fails for unknown keys)

From: Fabian Stelzer <fs@gigacodes.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Fabian Stelzer via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Han-Wen Nienhuys <hanwen@google.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	"Randall S. Becker" <rsbecker@nexbridge.com>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Hans Jerry Illikainen <hji@dyntopia.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Gwyneth Morgan <gwymor@tilde.club>,
	Jonathan Tan <jonathantanmy@google.com>,
	Josh Steadmon <steadmon@google.com>
Subject: Re: t7510-signed-commit.sh hangs on old gpg, regression in 1bfb57f642d (was: [PATCH v8 9/9] ssh signing: test that gpg fails for unknown keys)
Date: Wed, 22 Dec 2021 11:13:26 +0100	[thread overview]
Message-ID: <20211222101326.fwl3wphr3ev6c7wt@fs> (raw)
In-Reply-To: <211222.86ilvhpbl0.gmgdl@evledraar.gmail.com>

On 22.12.2021 04:18, Ævar Arnfjörð Bjarmason wrote:
>
>On Fri, Sep 10 2021, Fabian Stelzer via GitGitGadget wrote:
>
>> From: Fabian Stelzer <fs@gigacodes.de>
>>
>> Test that verify-commit/tag will fail when a gpg key is completely
>> unknown. To do this we have to generate a key, use it for a signature
>> and delete it from our keyring aferwards completely.
>>
>> Signed-off-by: Fabian Stelzer <fs@gigacodes.de>
>> +
>> +	cat >keydetails <<-\EOF &&
>> +	Key-Type: RSA
>> +	Key-Length: 2048
>> +	Subkey-Type: RSA
>> +	Subkey-Length: 2048
>> +	Name-Real: Unknown User
>> +	Name-Email: unknown@git.com
>> +	Expire-Date: 0
>> +	%no-ask-passphrase
>> +	%no-protection
>> +	EOF
>> +	gpg --batch --gen-key keydetails &&
>>
>The t7510-signed-commit.sh script hangs on startup with this change, and
>with -vx we show:
>
>    [...]
>    ++ git tag twelfth-signed-alt 17f06d503ee50df92746c17f6cced6feb5940cf5
>    ++ cat
>    ++ gpg --batch --gen-key keydetails
>    gpg: skipping control `%no-protection' ()
>
>This is on a CentOS 7.9 box on the GCC Farm:
>
>    [avar@gcc135 t]$ uname -a ; gpg --version
>    Linux gcc135.osuosl.org 4.18.0-80.7.2.el7.ppc64le #1 SMP Thu Sep 12 15:45:05 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
>    gpg (GnuPG) 2.0.22
>    libgcrypt 1.5.3
>    Copyright (C) 2013 Free Software Foundation, Inc.
>    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>    This is free software: you are free to change and redistribute it.
>    There is NO WARRANTY, to the extent permitted by law.
>
>    Home: ~/.gnupg
>    Supported algorithms:
>    Pubkey: RSA, ?, ?, ELG, DSA
>    Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
>            CAMELLIA128, CAMELLIA192, CAMELLIA256
>    Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
>    Compression: Uncompressed, ZIP, ZLIB, BZIP2

Hm. I have an identical centos 7.9 installation (same versions/features) and 
the key is generated without issues. Does the VM maybe have not enough 
entropy for generating a gpg key?
Otherwise we could of course pre-generate the key and commit it. I'm usually 
not a fan of this since over time it can become unclear how it was generated 
or if the committed version still matches what would be generated today.
But of course I don't want to slow down CI with rsa key generation stuff :/
If missing entropy is the problem, then maybe CI could benefit from 
something like haveged in general (other tests might want more entropy too).