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 Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx>

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@xxxxxxxxxxxx>
+
+	cat >keydetails <<-\EOF &&
+	Key-Type: RSA
+	Key-Length: 2048
+	Subkey-Type: RSA
+	Subkey-Length: 2048
+	Name-Real: Unknown User
+	Name-Email: unknown@xxxxxxx
+	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).




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux