I had assumed that GnuPG prioritized the safety of its users over strict adherence to a particular view of a cryptographic protocol

Looking at the table in random(7) it seems clear to me that what we want to just invoke getrandom() with no arguments. This blocks until the kernel's PRNG has been adequately seeded, but once seeded it doesn't block, while still pulling from an unbreakably-strong PRNG. this is the best-of-both-worlds situation that we want.

Changing the GnuPG long-term (and short-term) key generation techniques to use this approach might require coordination with gcrypt. gcrypt's gcry_random_level currently has GCRY_WEAK_RANDOM and GCRY_STRONG_RANDOM and GCRY_VERY_STRONG_RANDOM, which doesn't represent the nuance described above.

One approach might be to just have gcrypt on Linux treat all values of gcry_random_level the same, and use getrandom() for all of them.

that is true. however i still think the actual key fingerprint used should be
shown here. shouldn't we avoid short keyids everywhere?

well, it looks like i stand corrected: the problem happens both in encryption
and decryption. i *meant* to post about decryption, but i only pasted the setup
part... :p

[1012]anarcat@curie:~130$ rm foo
rm : supprimer fichier 'foo' ? y
[1013]anarcat@curie:~$ gpg foo.gpg
gpg: encrypted with 4096-bit RSA key, ID A51D5B109C5A5581, created 2009-05-29

"Antoine Beaupré <anarcat@orangeseeds.org>"

[1014]anarcat@curie:~$ ls -al foo*
-rw-r--r-- 1 anarcat anarcat 4 fév 6 13:16 foo
-rw-r--r-- 1 anarcat anarcat 594 fév 6 13:04 foo.gpg
[1015]anarcat@curie:~$ chmod 600 foo.gpg
[1016]anarcat@curie:~$ ls -al foo*^C
[1016]anarcat@curie:~130$ rm foo
rm : supprimer fichier 'foo' ? y
[1017]anarcat@curie:~$ gpg foo.gpg
gpg: encrypted with 4096-bit RSA key, ID A51D5B109C5A5581, created 2009-05-29

"Antoine Beaupré <anarcat@orangeseeds.org>"

[1018]anarcat@curie:~$ =k^C
[1018]anarcat@curie:~130$ ls -al foo*
-rw-r--r-- 1 anarcat anarcat 4 fév 6 13:16 foo
-rw------- 1 anarcat anarcat 594 fév 6 13:04 foo.gpg

thank you for taking time to formulate this correctly, dkg. :)

regarding symlinks, i got the idea from reading the caff source code. after a
quick chat with the caff author, i was pointed towards that discussion:

https://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029301.html

... where Werner Koch suggests symlinks as a solution.

in my opinion, the solution is sub-optimal: symlinks increases the attack
surface and adds un-necessary overhead. i would prefer an a commandline flag
(e.g. --agent-socket) or environment variable to be able to select relevant
agents...

the same applies to dirmngr, apparently - caff creates symlinks for both the
agent and dirmngr. i am not sure why, but i suspect I may have to do the same,
since I have seen stray dirmngr processes lying around in my session. a
different issue, maybe, but related, implementation-wise.

i prefer solution (c): we should assume utf8, if we are going to assume anything
at all.

if the user doesn't provide UTF8 *and* doesn't have the proper locale set, then
we should exit with a meaningful message.

that way, things break for people that don't have a properly configured locale
*and* try to input non-UTF8 as opposed to just fail if locale is *not
configured*, which is a pretty common scenario.