I've now run the proposed patch on a GNU/Linux system where the kernel's RNG is initialized but /proc/sys/kernel/random/entropy_avail shows numbers below 100, and i can confirm that 3072-bit RSA key generation takes roughly 1.6 seconds. (20 sequential keygen operations took 32s)

Here is another example of users doing sketchy things to try to "fix" this process:

Here is an example of the kinds of UI/UX mystery that users face while this decision is unresolved:

We do have a history of extending the API, no?

About how the keys are actually stored on disk:

ping again…

could i get feedback on this ticket? a simple, clean patch is available, and i don't understand what is blocking it.

i'm having trouble just assembling the two signatures over the subkey with 2.2.8 in a single homedir. in particular, when i try to do the following with a new, clean test GNUPGHOME, then i see only one signature on the subkeys afterward:

thanks, that works for me. I look forward to seeing the patches :)

can you let me know what you're planning so i can plan my work on enigmail?

thus far every packet type has been a three-letter string, right? I'm looking at "Field 1" in doc/DETAILS. adding a 4-letter packet type seems like it could be trouble if someone has done the dumb thing of assuming the field is fixed-length.

can i get a confirmation that the options you're considering for --with-colons --show-keys when confronted with a revocation certificate will be either:

By "dummy pub line" I think you're proposing output that looks something like this instead of just the rev: line.:

Revocation certificates consist of *only* the revocation packet, right? Claiming that the revocation cert contains more than the revocation packet (when it doesn't) seems more troubling from an API perspective than just telling people to expect a single rev: line if they are looking at a revocation certificate.

thanks for looking into this so quickly. where is your patch? i don't see it on the master branch yet.

ee1fc420fb9741b2cfaea6fa820a00be2923f514 contains a proposed fix for this.

I've just pushed e037657edaf0b3ee9d2e30f6fe3edf6879976472 on the fix-T4019 branch

see e051c279216ecd4ec9a48e13ccc695f5ab667b2a

I note that --import-options show-only --import has the same effect as --show-keys -- that is, the revocation cert is imported. so the error is in the import-options code itself. I'll push a fix-T4017 branch shortly with a proposed correction.

I've heard no critique of the logic above. could we get this fix landed? it is concretely useful for doing key generation on modern GNU/Linux systems.

fwiw, i agree that if there's any security vulnerability here, it is in the verification side, not the creation side.

@werner, what protocol design rule do you think is not being followed specifically?

please see the branch dkg/fix-T3995 with rG3308d5e3f4e25dce5168c4a7cb2f545424c6d185

I note that this problem could also affect a user with multiple identities, one of which has their decryption keys on a smartcard. If a message arrives encrypted to both identities, but the user does not have their smartcard available, they will hit the same issue.

I think i can understand why this decision was made, but i'm not convinced it's a great solution. In particular, string-based arguments for C libraries are asking for trouble, and compound string arguments of the type described above are even more risky.

See also Filippo Valsorda's 32c3 talk about CSPRNGs.

@gouttegd : setting only-urandom at the distro level problematic due to two factors:

Werner wrote:

we already use the getrandom system call if it is available

Thanks for the fix! however, the fix only addresses the two flags we currently know about. I've pushed a branch T3880-fix that tries to implement the If the agent does not support the requested flags […] It must reply with a SSH_AGENT_FAILURE message part of the spec.

The severe delay caused by check-trustdb continues to cause problems elsewhere in the ecosystem. It would be great to try to address this so that GnuPG was more responsive for routine tasks like importing a single key.

This is similar to T3622, but it's not the same thing.

hm, i think this is the file:

it is the decision of the user to use such a certificate.

Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.

it's too bad that this is not considered something worth fixing upstream -- at the moment, debian's python3-gpg will only work with one specific version of python3 because of this, which makes package transitions more complex than they should be.

Agreed, Signing subkeys can be useful for checking historical signatures. And even encryption subkeys *can* be useful after their expiration, e.g. when doing historical auditing.

When i read the manpage, nroff-formatted against an 80-column terminal, it says, literally:

Any fix for this should be included in the test suite to avoid a regression :)

This decision suggests that the accessibility of the current source tree
for new contributors (who are more likely to find the static, archaic
changelogs distracting) is unimportant.

I'm not sure why a special case should be needed -- failure to create
the .kbx should not be a failure for a decryption operation in general.

So, to protect against this attack, the client needs to do both of the following:

Here are two examples:

@werner suggests using an ephemeral home directory. this is an important point.

@justus asked for examples.