race condition on ~/.gnupg/random_seed when signing

[David Allouche]

Desired behaviour: Signing should always fail or succeed in a deterministic
manner, or provide a distinctive error message if a system failure (e.g. out of
memory) occurred.

Observed behaviour: Once in a while, when doing many concurrent signing
operations under heavy load, you can get an error looking the following.

gpg: fatal: can't read `/home/importd/.gnupg/random_seed': No such file or directory
secmem usage: 1472/1472 bytes in 4/4 blocks of pool 1472/32768
signature command exited with non-0 status (2)

command: gpg --clearsign --no-default-keyring --keyring
/<email address hidden>
--secret-keyring
/<email address hidden>
--default-key <email address hidden>

Interpretation: the .gnupg/random_seed might be updated in an unsafe manner,
leaving a race window where the file does not exist.

Security implications: None. Triggering the race requires write access to
.gnupg. If an attacker has it, you have a way bigger problem.

Note: we hit this problem repeatedly when doing source imports.

[David Allouche (ddaa)]

It appears that this problem has been partially fixed since I filed this bug. When mass-signing the bzr branches of importd, I got a number of similar messages, but they were no longer fatal errors.

Some googling revealed that the problem is known to upstream, and that the warning is displayed because when the random seed cannot be read, a new one has to be generated, leading to reduced performance and/or greater entropy consumption (I do not remember clearly which).

As far as I'm concerned, the bug no longer matters since the race condition is no longer fatal.

[Daniel Silverstone (dsilvers)]

Given that it is no longer fatal and that upstream are quite aware of the situation, do you feel this bug should remain open? If not, please close it.