For GnuPG 2.2, it's better to be conservative (least change of behavior, if any).
Thu, Nov 25
My proposal is applying SOS (MPI with leading zero octets) patches, for 2.2, because there may be existing keys with SOS already.
It's not yet solved.
Tue, Nov 23
I guess this is solved. Feel free to re-open and schedule for 2.2.34
Might be a TOR Thing?
Sat, Nov 13
Fri, Nov 12
Nov 3 2021
Oct 27 2021
Sure there are logs, see the options log-file and debug in the man pages.
To sign using specific subkey or the main key, use the fingerprint of the key and append an exclamation mark.
Oct 22 2021
I put my initial try by rG752422a792ce: scd: Select a reader for PC/SC..
Oct 20 2021
Yes, but it is more complicated to do because you need to download a binary version of the keys and check that they are authentic. Most users don't known it. Anyway, I meanwhile created a Brainpool release sign key and new VSD releases are signed with that. The override option does not really harm, but we can close this bug due to the new release key.
Oct 14 2021
Oct 13 2021
Wouldn't it be safer to use gpgv for verifying the signature than to add a code path to gpg to circumvent the hard de-vs compliance check?
Oct 12 2021
On my new Windows 10 laptop I see a "Windows Hello for Business 1". Thus put everything with "Windows Hello" at the end of the list or skip unless a reader-port is set. IIRC there are device with "virtual" or "Virtual" in their name, they don't make sense for us either. I would also put devices with "SCM" or "Identiv" to the top of the list. In particular the substrings "SPR532" seems to identify the Identiv SPR332 which is what we use here and actualay a suggested reader for GnUPG VS-Desktop.
Please tell me reader names to skip.
Oct 11 2021
Oct 8 2021
There won't be any other 3.1 release - install GnuPG 2.2.32 on top of Gpg4win 3.1.16
My experience on a Window 10 system (with Gpg4win 3.1.15 which has GnuPG 2.2.27) was, that removing the expired root certificate did not help with https://keyserver.ubuntu.com and the intermediate certificate was not in the windows store, so it could not be removed.
Removing an intermediate cert from your local system doesn't help because any correctly configured server will send you all necessary intermediate certs together with the server cert. You'd have to remove the expired root certificate instead (see Workaround 1 on https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/). The problem is that this will break certificate verification for any servers that still use the old intermediate cert, e.g. keyserver.ubuntu.com.
Oct 7 2021
The LE web site has instruction on how to do this. However, it is complicated and depends on your system. The intermediate cert you listed is signed by the expired old root cert. If you remove this intermediate cert the other root cert will be found and we are done. The old LE certs had a 4 tier chain and the new one a 3 tier.
See https://dev.gnupg.org/rG341ab0123a8fa386565ecf13f6462a73a137e6a4 and https://letsencrypt.org/images/isrg-hierarchy.png
One problem I see is that keyserver.ubuntu.com delivers a problematic intermediate(?) certificate:
If there is no easy way to install a new version of GnuPG, e.g. for Gpg4win or for GNU/Linux distributions: It may make sense to have instructions for the workaround ready.
Oct 6 2021
Please update to 2.2.32 if you have problems with keyservers etc.
Backported to 2.2.32