- User Since
- Mar 27 2017, 4:49 PM (171 w, 4 d)
Thu, Jul 2
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?
Wed, Jul 1
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.
Tue, Jun 30
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.
Thu, Jun 25
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.
I think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?
Thanks for the quick fix, @werner!
Mar 18 2020
I thought i'd try with other certificates. I started with the one from this website. It also fails to validate unless i supply --disable-crl-checks, apparently because the immediate issuer (the Let's Encrypt CA) doesn't offer CRLs, only OCSP responders. Perhaps --disable-crl-checks should be the default, or at least if there is no CRL available there shouldn't be a failure by default:
Aha, i can get it to say f if i use --disable-crl-checks:
i didn't know that, thanks. i'm now seeing i (which i think means "invalid") in the same configuration:
Mar 12 2020
For reference, here's an error message from openssl smime when it is trying to verify an e-mail message with no embedded certificate at all (despite it knowing about the relevant certificate):
Mar 10 2020
"log" and "lock" are easy typo/confusions to make, @aheinecke was just trying to understand your report better, since there wasn't much information in it.
@wiktor-k, "just extend the spec" doesn't necessarily work with existing clients, which might be surprised to find unexpected packets in the signature section of an e-mail. It seems more likely to me that they'd be able to handle (meaning: ignore) an unknown subpacket (as long as it's well-formed) than to handle additional packets. But all of these surmises require testing with existing clients, of course. Has anyone done any of that testing?
Ah, thanks for pointing out the subpacket option (i guess it could be hashed or unhashed). i don't think any of the subpackets currently defined in RFC4880 supports this use case -- but i guess you could mint a new one, or use a notation.
Mar 9 2020
Hi @aheinecke, thanks for thinking about this, and thanks for tagging me here too. I'm definitely interested.
This is an important fix for a sensible S/MIME use case. Thanks for working on it!
Yes, i'd surmised that the ::::: lines are continuation lines of the error message. but why not just percent-escape the newline in the error message too? Where in the documentation of this API does it say to expect continuation lines of error messages? Is gpgconf expected to be used programmatically?
using enigmail with the new version
Mar 6 2020
I think you mean "mix", not "fix". right?
Mar 5 2020
Sure, I personally know that GnuPG requires a homedir to operate.
Mar 4 2020
Feb 28 2020
i'd be unlikely to ship anything as /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf just because of the mess that admins have to deal with when shipped config files change.
Feb 27 2020
I think this might be the same as T4820.
Feb 26 2020
I think this is a great feature to have. Thanks for working on it, @aheinecke .
I've just pushed ad55de70930543c1681b11e4bd624be074122b23 onto branch dkg/fix-4855 as a proposed fix, to permit --trusted-key to accept a full 20-byte fingerprint.
Feb 21 2020
Werner could you maybe at least check for an internet connection, I don't know how to do it on Linux but on Windows it's easy because windows has API for that.
Feb 19 2020
Feb 5 2020
I've just tested this with GpgOL 2.4.6~beta3 as well, and while the i see the same issue :( (though the legacy display part is not shown, thanks to your fix of T4796).
Thanks! taking screenshots is definitely tedious. I just redid the screenshots for all the sample pgp/mime messages with GpgOL 2.4.6-beta3, and i can confirm that it looks like you've resolved the matter.
Feb 4 2020
Jan 29 2020
Avoiding a failure for older versions means that the test suite won't catch this particular bug if it is reintroduced in future versions. That seems suboptimal for me, but given the complexity of the dependency chain, i don't know how to solve it. I prefer just raising an error with older versions of GnuPG as with rMf2aeb2563ba2 , as this is a test of the json interface, which isn't in widespread use yet.
Changing back to wontfix given the wontfix resolution of T4826
This is not a problem for 2107 (when you and i are 6 feet under). it's a problem well before then for anything that has an expiration date of 2107 or later (as demonstrated by the legitimate example certificate here today).
This is a problem for gpgv and gpg as well. gpg reports:
It looks like at least for OpenPGP, the layer below GPGME is also broken for expiration dates in this time window (see T4826)
-----BEGIN PGP PRIVATE KEY BLOCK-----
-----BEGIN PGP PUBLIC KEY BLOCK-----
Jan 28 2020
I don't mind a workaround that avoids an ABI/API fix as long as it defers actual failures until 2038.
I'm reopening this because i think users of these 32-bit platforms are going to run into issues before 2038 happens. Certs could appear expired before they are actually expired, for example, because of the wraparound time.
Jan 27 2020
Jan 24 2020
(if you don't want to publish the full strace output here because you're concerned it might leak some information about your machine or your network, but you're ok sharing it with me personally, you can send it to me privately by e-mail, encrypted to the OpenPGP certificate with fingerprint C4BC2DDB38CCE96485EBE9C2F20691179038E5C6, and sent to one of the e-mail addresses associated with that certificate. please make a note here if you do that)
ok, that's deeply weird. i'm assuming that this machine has IPv4 connectivity. I have no idea why dirmngr would be returning EAFNOSUPPORT in that case.
branch dkg/fix-4821 contains a fix for this, in commit 414938cfedbdb97b83d00e8619dec9502096be22
The dkg/fix-4820 branch now has these two fixes.
Jan 23 2020
For easier reference or searchability, the test error looks like this:
This appears to be a different error than above. here we see:
Jan 22 2020
this looks to me like a problem with the TLS handshake -- it looks like this is a response coming from the TLS stack -- as rfc 8446 says, alert 49 is access_denied: