Fri, May 29
Thu, May 21
Fixed in master and applied to 2.2 branch too.
Apr 16 2020
We do this now always if --auto-issuer-key-retrieve is set. Also backported to 2.2
Apr 15 2020
Apr 14 2020
Data (ie.e CMS) signatures do now also work.
Apr 9 2020
I'm honestly surprised this isn't being given any sort of priority.
gnupg for windows is simply broken. Even Kleopatra, its supplied and designated key management application doesn't work re: keyserver communication.
Okay certificate and CRL checking does now work with rsaPSS. Need to work on data signatures and check the compliance modes.
Apr 8 2020
I started to work on it so that I can actually use the certificates on my new D-Trust card. This will be a verify-only implementation.
Mar 31 2020
Mar 9 2020
I'm using enigmail 1.9.9 because I'm on a mail client that doesn't use WebExtensions, so it's using gnupg for keyserver stuff. In this case that means I've been able to verify it's a gnupg issue (both Kleopatra and enigmail displaying the same issue as CLI).
using enigmail with the new version
Just registered to report pretty much the same.
I've been using gpg 2 for a long while and it's been doing just fine, up to the point where people started using keys it didn't recognise that require a later version.
Mar 5 2020
It is actually questionable whether PSS is a better padding scheme than PKCS#1, see
https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html . PSS seems indeed be rarely used; quoting Peter from a followup on his writeup: “If I get time over the weekend, and I can find a CMS message signed with RSA-PSS, I'll create a forgery using xor256.”
Mar 4 2020
To summarize: The DGN CRL uses a the RSA-PSS Padding / Signature Scheme. ( https://de.wikipedia.org/wiki/Probabilistic_Signature_Scheme )
Feb 26 2020
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
But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.
and by that bypassing all key source tracking as done by gpg. In any case searching by name or mail address on a keyserver should not be done - at least not by a GUI tool as used by non experienced users.
I agree that this is a tricky problem, but it should really be improved.
The problem is not to check whether there is a connection but on how to decide whether something is a pool or an explictly added single keyserver and how often should we try to connect or read from it. Without marking hosts as dead the auto search features won't work well.
@Valodim probably not so much as dirmngr might behave differently and not mark hosts as dead.
The proper solution is of course to use pkill instead of killall. SCNR.
I can attest to the "growing bit of popular lore": Roughly half the support requests I get to email@example.com boil down to an exchange of "it just doesn't work with a 'general error' message" -> "try killall dirmngr" -> "that did it". I have heard similar stories from @patrick from Enigmail users, and more than once heard people applying poweruser trickery like "I just have killall dirmngr in my resume.d".
Nov 26 2019
The LDAP code is actually in very bad shape because @neal added it without utilizing the ldap wrapper and thus a timeout won't work reliable.
Nov 25 2019
Unusable v6 interfaces are now detected on Windows and then not used.
Nov 23 2019
The manual states that --standard-resolver is mostly for debugging. The reason you get an "not enabled" is that we can't allow direct DNS queries in Tor mode which would happen with the system (standard) DNS resolver.
Nov 11 2019
See also D475.
Oct 25 2019
Oct 24 2019
There is a growing bit of popular lore in the GnuPG community that "when keyserver operations fail, you solve that problem with killall dirmngr." I believe this suggestion is potentially damaging (the long-running daemon may be in the middle of operations for a client that you don't know about), but i suspect it is circulating as advice because it resolves the situation outlined in this ticket. For whatever ephemeral reason, dirmngr gets stuck, and fails to notice that this situation has resolved itself.
Oct 17 2019
GnuPG ships a non-PKI certificate, specifically to authenticate hkps.pool.sks-keyservers.net. Now due to an implementation detail, this has been shown to potentially lead to authentication of other domains by this certificate, if a maintainer changes the default keyserver via the DIRMNGR_DEFAULT_KEYSERVER variable in configure.ac. Now arguably, this variable isn't exposed via ./configure, so it's not "officially" configurable - but evidently maintainers do want to change it. A trivial one-line patch was supplied to change the unintended and potentially security-problematic behavior into the (I believe) obviously intended one.