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 2021-12-22 at 10:13:26, Fabian Stelzer wrote:
> 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

Attachment: signature.asc
Description: PGP signature


[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