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>
- Date
- Dec 22, 2021, 10:13 UTC
- Message-ID
- <20211222101326.fwl3wphr3ev6c7wt@fs>
- In-Reply-To
- <211222.86ilvhpbl0.gmgdl@evledraar.gmail.com>
On 22.12.2021 04:18, Ævar Arnfjörð Bjarmason wrote:
Show 51 quoted lines
> >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).