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: brian m. carlson <sandals@crustytoothpaste.net>
Date: Dec 22, 2021, 15:58 UTC
Message-ID: <YcNLOsuAh85ecKw4@camp.crustytoothpaste.net>
In-Reply-To: <20211222101326.fwl3wphr3ev6c7wt@fs>

On 2021-12-22 at 10:13:26, Fabian Stelzer wrote:

Show 9 quoted lines

> 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).

GnuPG is notorious for using /dev/random for generating keys, so yes, this is likely to block in a variety of situations. We don't see this on newer systems because they've replaced the blocking /dev/random with a non-blocking one except for when the CSPRNG hasn't been seeded at least once.

The problem isn't lack of entropy, but the fact that there's no reason to use /dev/random since /dev/urandom is suitable for all cryptographic needs once initialized. On modern versions of Linux, one just uses getrandom(2), which deals with the uninitialized case and otherwise doesn't block. However, CentOS 7 is old.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA