- User Since
- Mar 27 2017, 4:49 PM (68 w, 6 d)
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:
Sat, Jul 14
We do have a history of extending the API, no?
Thu, Jul 12
About how the keys are actually stored on disk:
Mon, Jul 2
Jun 19 2018
could i get feedback on this ticket? a simple, clean patch is available, and i don't understand what is blocking it.
Jun 18 2018
Jun 14 2018
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?
Jun 13 2018
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:
Jun 12 2018
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
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.
Jun 11 2018
Jun 9 2018
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.
Jun 8 2018
fwiw, i agree that if there's any security vulnerability here, it is in the verification side, not the creation side.
May 29 2018
@werner, what protocol design rule do you think is not being followed specifically?
May 25 2018
please see the branch dkg/fix-T3995 with rG3308d5e3f4e25dce5168c4a7cb2f545424c6d185
May 1 2018
Apr 28 2018
Apr 26 2018
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.
Apr 19 2018
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.
Apr 16 2018
Apr 14 2018
@gouttegd : setting only-urandom at the distro level problematic due to two factors:
Apr 13 2018
we already use the getrandom system call if it is available
Apr 12 2018
Apr 11 2018
Apr 10 2018
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.
Apr 5 2018
Mar 27 2018
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.
Feb 27 2018
Feb 23 2018
This is similar to T3622, but it's not the same thing.
Feb 21 2018
hm, i think this is the file:
Feb 6 2018
Feb 4 2018
Feb 2 2018
Jan 31 2018
it is the decision of the user to use such a certificate.
Jan 30 2018
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.
Jan 12 2018
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.
Jan 11 2018
Jan 3 2018
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.
Dec 31 2017
When i read the manpage, nroff-formatted against an 80-column terminal, it says, literally:
Dec 29 2017
Any fix for this should be included in the test suite to avoid a regression :)
Dec 21 2017
Nov 30 2017
Nov 21 2017
Nov 19 2017
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.
Nov 17 2017
Nov 15 2017
Nov 13 2017
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.
Nov 12 2017
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.