- User Since
- Mar 27 2017, 4:49 PM (267 w, 6 d)
Mon, May 2
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.
Fri, Apr 29
Thu, Apr 28
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.
Wed, Apr 27
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.1135220.127.116.11 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.113518.104.22.168 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
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
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.
Jan 15 2021
This ambiguity appears to be the cause of a recent epic (and to me, largely incomprehensible) thread on gnupg-users. It would be great to have the WKD guidance about fallback strategy be much more explicit. Any room for ambiguity here leads to different outcomes from different WKD clients, and quite a bit of confused discussion by their users.
Dec 11 2020
Nov 18 2020
Aug 18 2020
Aug 10 2020
We currently already ship:
Jul 2 2020
I don't think this fix has made it into a release yet. Could we get a released version of gpgme that contains this fix?
Jul 1 2020
on #debian-dpkg on IRC, Guillem Jover suggested that we might want to fix dpkg specfiles to use +self_spec: instead of *self_spec:.
I'm still not understanding what specifically should be fixed here. Sorry to be dense about it, but the range of options and configuration details that are different are pretty puzzling.
Jun 30 2020
The same concern has been reported at https://bugs.debian.org/964033 -- if dirmngr is not going to follow the specification, it should at least document (and maybe warn?) about how it is divergent.
Jun 25 2020
Can you characterize the failure when ipv6.disable=1 ? The straightforward failure (connect() fails with EHOSTUNREACH after a few seconds) should presumably be treated the same as if some other host happened to be offline. That should result in dirmngr failing over to the next available address for the configured keyserver, right?
I agree with you that a certificate with a lengthy expiration is not cryptographically sensible or wise, @bernhard -- i'd never want to produce such a certificate myself.
Jun 11 2020
This appears to still be a problem, despite upgrading to libksba 1.4.0:
May 29 2020
May 20 2020
If there's no objection to this in a few days, i'll go ahead and merge it to master.
May 19 2020
branch dkg/fix-4952 contains this fix in an easily applicable form as 0db8c768843db3e85935b972f1ed9d1b98159c46
Mar 31 2020
Mar 30 2020
Mar 29 2020
Thanks for following up!
To be clear: marking this ticket wontfix means (among other things) that it is the GnuPG project's upstream position that:
Mar 26 2020
OK, i've asked on gnupg-devel.
Mar 23 2020
Mar 20 2020
Mar 19 2020
I see no difference between the last two example stanzas that show you running ../run-verify. Are they supposed to have different output?
I'm aware of the metadata leakage risks of OCSP, and i share your concerns about them.
If CRLs or OCSP are a MUST in a given profile, and the cert chain has OCSP but no CRL, it seems like that profile should then try OCSP, rather than failing.