- User Since
- Mar 27 2017, 4:49 PM (78 w, 1 d)
Sun, Sep 23
i note that my patch doesn't include an addition to the test suite, which it probably should, though i'm not fluent in gpgscm. if someone could update it to include a test, i'd appreciate that, and would probably learn from the commit. I imagine the test would do something like:
I tried to push commit 07c19981da0607dc442fadc4079b1d71fbef8f83 to branch dkg/passphrase-env on playfair, but i got this complaint:
Wed, Sep 12
sorry, i haven't had time to test gpgme with those changes myself. i hope someone can do so.
if gpgme doesn't rely on the return value, but instead on parsing the --status-fd for errors, then there will still be an ERROR printed:
yes, it looks like using --no-keyring does change the return code from 2 to 0 for me.
Fri, Sep 7
Wed, Sep 5
well, i tried to push, anyway, but it looks like playfair is rejecting my pushes:
@werner -- yes, i am asking for a change that is specific to the way that gcrypt interacts with the Linux kernel. The minor patch i've proposed only affects a codeblock within #if defined(__linux__), so i don't believe it would have an effect on other Unices. I hope that people working with other kernels will propose any necessary fixes for them.
Aug 23 2018
@aheinecke thanks for the followup!
Aug 2 2018
This bug report has been around for several months now. it has a simple patch, a clear explanation, a report of running code, and examples of problems it solves.
Jul 22 2018
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 0.8 seconds: 20 sequential default --quick-keygen operations (each creating two secret keys) 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:
Jul 14 2018
We do have a history of extending the API, no?
Jul 12 2018
About how the keys are actually stored on disk:
Jul 2 2018
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 :)