Interesting. i'm also not sure this is a good feature. I also still don't think the gpgv man page explains this clearly, but if you don't want to clarify it, i won't bother re-opening this issue.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 25 2024
Thanks for this prompt fix! but they're still not aligned. with this fix, the Synopsis is:
Jul 21 2024
Jun 4 2024
All applied and more fun with cherry picking in the future ;-)
Jun 1 2024
fwiw, i've just shipped a patch to correct this change in behavior in the 2.2 branch debian. Many thanks to @gniibe , on whose work in the 2.4 branch this is based, and to @ametzler1, who did the backporting to 2.2. I've also written a test which tries to tickle this bug. It fails with unpatched 2.2.43 as emacs times out signing and encrypting mail as epg.el deadlocks with gpg.
May 31 2024
that looks like it was a problem in the original text, not something i introduced. If you find anything else that needs fixing, please go ahead and fix it to! no need to wait for me.
May 30 2024
It seems too late to reject on import, given that people might already have such a secret key in their ~/.gnupg/private-keys-v1.d/ They might have had it for years without knowing it, because the failure is so intermittent. They might just think that they did something wrong, and when they try again it works. It would be great to be more robust than that.
May 29 2024
Maybe there's a 4th possible option that's better than the three i identified?
So i see a range of ways that any OpenPGP software could deal with this:
May 28 2024
May 27 2024
Are you saying that concern about "risking a regression" is the reason to not fix this bug, which is itself a regression, and was introduced into the a point release in the current "long term support" branch?
May 17 2024
May 16 2024
Thanks! please consider adding it to 2.2 and master as well. I suspect it's more outdated than it would be if it had been shipping in the upstream tarball.
May 14 2024
I note that @DemiMarie offered a patch for this over a year ago. It doesn't appear to have had any review. If it's good, maybe apply it? If it's problematic, can we identify the problem?
May 13 2024
by all means, please proofread it! thanks for the attention to detail. what was the grammar glitch?
Apr 26 2024
I understand the desire for stable behavior, and i agree that a change here might affect verification of existing signatures (and might mean producing signatures that will be misinterpreted by older versions).
Mar 8 2024
I have also not found a straightforward way to correct a cross-signature that was made with a weak digest algorithm using GnuPG.
Feb 2 2024
The patch supplied here should apply to STABLE-BRANCH-2-4, but it should also be easy enough to backport to STABLE-BRANCH-2-2 and STABLE-BRANCH-1-4. For GnuPG master, i recommend actually removing the option.
Dec 26 2023
One use case that seems sensible to me is to try to convince a long-running operation (e.g. a sequence of key generations) to all use a single timestamp. In this scenario, there's no interest in setting the clock to be some variant of the current time, just an interest in it remaining fixed across all the operations.
Sep 26 2023
Aug 16 2023
It looks to me like it's marginally more common to *not* use the lib prefix for pkgconfig files:
Nov 2 2022
Oct 20 2022
@werner i'm not sure i understand what "easy to enclose them in angle brackets just for comparison" means.
Oct 17 2022
I recommend, when making a User ID with only an e-mail address, to populate the User IDs by wrapping it in an angle bracket, rather than just leaving the raw e-mail address. It's not just the regexp matcher -- there are other pieces of OpenPGP software that won't recognize a raw e-mail address in a user ID as an e-mail address. It also makes it easy to distinguish such a User ID from a User ID that is not at all an e-mail address.
Aug 30 2022
Thanks, @gniibe -- i agree that this change to put_cert should be helpful, when encountering a certificate that is already invalid.
Aug 25 2022
Thanks for the followup about R3, @mpilgrem! Looking at your logs in more details, and the source code for find_cert_bysubject in dirmngr/certcache.c, i think i see what the issue is. It's slightly more subtle than not terminating early if a known trusted root can validate a truncated chain.
Aug 24 2022
@mpilgrem, i'm glad that removing the DST Root CA X3 from your windows control panel worked for you, but it still doesn't seem to be a reasonable fix from a GnuPG user perspective
Aug 23 2022
@mpilgrem: in the meantime, for connecting to keys.openpgp.org, which *has* cleaned up its certificate chain, you might also want to try killing your dirmngr process, and/or cleaning up the data in .gnupg/dirmngr-cache.d/.
Basically, the website in question (e.g. https://openpgpkey.gnupg.org/, which exhibits this problem) serves up three certificates:
May 23 2022
I see the patch which does look like it will guarantee that the test suite succeeds. But does it solve the underlying problem, though? I worry that it might just paper over a more subtle problem.
May 21 2022
May 2 2022
Debian requires all builds to use software that we have local copies of in the archive, which appears to rule out the use of speedo (it fetches source over the internet during build). So i've modified debian packaging to annotate that the Windows builds need a different version of libgpg-error than that defined in configure.ac.
Apr 29 2022
this looks similar to https://dev.gnupg.org/T5935 and https://bugs.debian.org/1008573
Apr 28 2022
Thanks for working on this, @gniibe! Maybe it would be useful to add a test to the test suite that tries to import and use a secret key of this particular structure.
Apr 27 2022
Jan 19 2022
thanks, looks good!
Jan 17 2022
Thanks for looking into this, @gniibe! over on https://bugs.debian.org/1003313 Helmut is asking for a re-consideration because he wanted to match arm-linux-musleabihf. Would you be ok with a change like my proposal rE371d1c952297f781277b979a4662859ec80fe836 (on branch dkg/expand-musl), that expands *-*-linux-musl to *-*-linux-musl* ?
Jan 11 2022
Thank you, @gniibe ! i'm applying your change to the debian packaging as 1.43-2. i'll let you know if it doesn't satisfy the folks trying to crossbuild debian on top of musl.
Jan 9 2022
Jul 29 2021
I share your concerns about centralization of keyserver infrastructure. Rejecting this security fix doesn't help keep keyservers decentralized, though.
Jun 4 2021
Do we want to encourage multiple cleartext wire-format representations of the same secret key?
Jun 3 2021
I've mentioned this interop issue (and tried to propose clarifying language for the revised standard) in the IETF OpenPGP WG mailing list.
Jun 2 2021
I think rGba321b60bc3bfc29dfc6fa325dcabad4fac29f9c has nothing to do with interoperable formats -- how things are stored in ~/.gnupg/private-keys-v1.d is unrelated to the interoperable transferable secret key format specified in 4880 or its revisions.
The problem here appears to be that the "MPI" of the curve25519 secret key is not actually a standard-issue big-endian OpenPGP MPI -- it's an opaque bytestring expected to be passed to the underlying "native" implementation of x25519, in the same way that the secret key is handled for Ed25519.
investigating the subkey in python:
looks to me like you've got the byte ordering of the Curve25519 secret subkey reversed from the way that GnuPG expects it.
fwiw, gpg-agent complains that the keys don't match:
Jun 1 2021
why not use gpgconf with the dirmngr component to set the keyserver option there?
May 27 2021
May 26 2021
Another solution to make life easier for gpgme users encountering this stuff would be if gpgme itself knows which uid is a DN and which is not, it could populate the gpgme_user_id_t.address field with content of the 1.2.840.113549.1.9.1 DN component. (or maybe gpgme_user_id_t.email, or both? as a user of gpgme, i don't really understand the difference between these fields)
fwiw, RFC 2253 is obsoleted by rfc 4514 -- which also doesn't have 1.2.840.113549.1.9.1 associated with "EMAIL", but does provide more detailed guidance for implementers of DN-to-string (and string-to-DN, to the extent that this is possible) conversions. Maybe the code should be updated to refer to the non-obsolete specification at least.
I'm reporting this because the above message renders poorly in notmuch -- notmuch gets the user ID from gmime's g_mime_certificate_get_user_id, and gmime populates that field from the uids field of a gpgme_key_t object, and gpgme pulls uid information from gpgsm --with-colons.
Attached is a proposed patch.
Attached is an even worse PKCS7 blob, that should be validatable given reliance on ca.rsa.crt, but it will be rejected by gpgsm because the PKCS#7 bundle includes ca.rsa.cross2.crt in it.
May 25 2021
OK, i have replicated this successfully with no ed25519 involved. here's the new intermediate cert:
Which NIST test suite are you referring to? It might not cover certificate pathfinding in the face of multiple cross-signed authorities.
May 21 2021
Apr 21 2021
Apparently only one of the secret keys is actually imported: the decryption key, but not the signing key.
Feb 25 2021
thanks, @werner!
Feb 24 2021
Thanks for the fixes, @werner!
Other ways that gpgsm --quiet is not quiet:
Feb 19 2021
I don't think the patch made elementary and ecore-x dev headers an absolute hard requirement; in particular, ./configure --disable-efl works fine to build pinentry without having these headers installed.
Feb 18 2021
Thanks for the verification, @wltjr. I've pushed 19a18ba5fee049aac87b5114763095aaeb42430f to the master branch for future releases.
hm, actually, maybe the efl should be EFL in order to produce and substitute the EFL_CFLAGS and EFL_LIBS variables.
@wltjr maybe it needs ecore-x as well as elementary > 1.18 in the PKG_CHECK_MODULES line? oh, and looks like i screwed up and used > where i should have used >= sorry! fixing those would make the PKG_CHECK_MODULES line be:
I think you're saying "GnuPG will reject all subpackets marked with a critical flag unless there is a specific known semantic for *criticality* for that subpacket" Am I understanding that right? Is there a published list of criticality semantics that GnuPG is willing to accept? How do those semantics differ from standard semantics for the packet in question?
Feb 17 2021
fwiw, i think a patch like this ought to work with reasonably-modern versions of autotools:
@wltjr maybe you could take a look at this?
Feb 12 2021
Feb 9 2021
RFC 4880 says:
Jan 29 2021
See also https://gitlab.com/openpgp-wg/webkey-directory/-/issues/3 which is the same issue.