Fixed in 2.2.36.
Fixed in 2.2.36.
Please note that due to vacation issues the signatures use the gnupg.com Brainpool based release key and some Linux distributions come with Brainpool removed from GnuPG.
Thu, Jun 23
Wed, Jun 22
Tue, Jun 21
My intention to refer rG7b1db7192 was to specify the HEAD of STABLE-BRANCH-2-2, meaning "the head of STABLE-BRANCH-2-2 today". The commit itself has no meaning.
Mon, Jun 20
I fixed the title, because it is not a Windows only issue.
The mentioned "g10: Fix garbled status messages in NOTATION_DATA" has nothing to do with the problem. So it can'r be the actual cause. Anway, I hope to get a 2.2.36 out this week.
I can replicate the error by 2.2.35, but I cannot replicate it with rG7b1db7192.
Fri, Jun 17
The likely cause is that the secret key is not protected. Problem seems to be in gpg-agent.
Looking again at your report, I don't think it is an IPC problem (bad magic cooky was my assumption). I can replicate this with the current 2.2 but not with 2.3. Both un Unix.
Thu, Jun 16
You deleted the socket file but you did not restart the agent. Thus gpg can't contact the agent anymore. On Windows we use a socket emulation which requires the socket's file only for a new connection (to get the port and magic cookie).
Thu, Jun 9
Backported to GnuPG 2.2.
Jun 7 2022
A use case for this is to allow the use of S/MIME for de-vs mode and for standard mode while clearly indicating compliant certificates. As of now all certificates matching compliant algorithms are indicated as compliant. The new flag could be used to distinguish between them.
Jun 1 2022
May 25 2022
Pushed the solution which doesn't require new flag for libassuan.
^-- I withdraw the solution (with error value) above.
May 24 2022
Or, it would be good for client side (in this case, gpg-agent) to specify the flag in the inquiry callback, that is, it's a kind of transient flag for a single transaction.
Revised version with new flag ASSUAN_CLEAR_INQUIRY_DATA.
May 20 2022
May 19 2022
For this particular issue of assuan_inquire, if it's needed, the point we should fix is:
May 18 2022
AFAICS, we need to implement a new Assuan flag and wipe the data passed to the callback after the callback returned.
May 14 2022
I just wrote a blog article about this problem
May 13 2022
Thanks for opening a ticket.
May 12 2022
Editing a formatted password should work now as expected.
Its an issue of cursor position. If one either deletes or inputs a a character anywhere in the password string, the cursor always jumps to the end of the string.
May 11 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 30 2022
it would be useful to add a test
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.
Use our build system and things work. In particular you need to use the software versions as listed at versions.gnupg.org and available via the build-auch/getswdb.sh. Even better use the speedo build system for Windows. Everything else is not a supported build configuration.
Thank you for the report.
The fix was not right, because gpg-agent side are not changed. See T5953.
Apr 27 2022
Apr 25 2022
Was fixed in 2.3.5
Apr 14 2022
We have not seen this problem anymore in recent versions. Thus closing.
We have a solulion for this bug. For further improvements we will use T5882.
- Fixed in 2.3
- assert replaced by a fatal error message
Apr 13 2022
Apr 7 2022
Updated the copy on our mirror as welll as the gpg4win and swdb packages files.
Apr 5 2022
The fix is from 2018 but was not picked up widely; see
Mar 29 2022
Not applying the change to GnuPG 2.2, users can use GnuPG 2.3 for that.
Mar 24 2022
Merged into T5804.
Mar 23 2022
Thank you. Confirmed.
Mar 22 2022
Mar 21 2022
Actually this is pretty obvious; we better ignore such misbehaving servers.
No need for callbacks actually. We can do it in a simpler way. See commit rGe5ef5e3b914d5c8f0b841b078b164500ea157804
Mar 17 2022
SWDB updated - thus the latest zlib will be part of the next Windows build.
I think that the particular issue of Let's Encrypt Certificate was handled correctly already.
Mar 16 2022
I think that this commit rG8fd150b05b74: gpg: Remove all support for v3 keys and always create v4-signatures. matters.
Mar 15 2022
All 4 CVEs are findings related to standard conforming compiler optimizations which OTOH break long standing assumptions on C coding. “Let us show that our compiler produces the fastes code ever and ignore any assumptions coders had made over the last 50 year”.
Mar 9 2022
Great, thank you very much!
Thanks for notifying. Will be fixed in the next release (mid Apri).
Fixed in master and 2.2 branch.
Mar 8 2022
I located the cause; Current implementation cannot parse the data like:
2611:d=5 hl=4 l=1632 cons: cont [ 0 ] 2615:d=6 hl=4 l= 500 prim: OCTET STRING 3119:d=6 hl=4 l=1124 prim: OCTET STRING
Mar 7 2022
Feb 28 2022
do you mean "dirmngr on Windows choses this one"? As in my mental model, dirmngr only loads all certifices from the windows stores on startup, but not during operations when requests come in (I maybe wrong though, I did not inspect the source code on this).
But in Windows 10 I get nothing in the certs.log file.
Feb 26 2022
Feb 25 2022
echo BYE | dirmngr -vv --server 2>certs.log
@TheParanoidProgrammer this looks like a very good and thorough analysis, thanks again!
Feb 24 2022
Ok, I managed to find 48504E974C0DAC5B5CD476C8202274B24C8C7172 via Powershell. It was in the CA store of my non-privileged user and since I always checked the certificate store as administrator it did not show up there. After removal of this intermediate certificate I am able to use hkps://keyserver.ubuntu.com.
Ok, so order of loading is not a problem since the cache does not store them by insertion order, but instead indexes them by the first byte of their fingerprint.
So, I think the problem here is that the expired intermediate certificate (48504E974C0DAC5B5CD476C8202274B24C8C7172) is somehow loaded in Windows and since its fingerprint's first byte is less than the server-supplied intermediate (A053375BFE84E8B748782C7CEE15827A6AF5A405) Windows chooses this one. I can see that the expired intermediate certificate is indeed loaded on Windows if I increase verbosity of dirmngr logs. However, I am still unsure where this certificate lives. The log says it comes from the "CA" store, but searching for it visually or by fingerprint search in Windows Certificates Snap-In (MMC) does not let me find it.
I will keep looking, but if you want to reproduce in your VMs, I suppose adding the expired intermediate certificate and the expired root certificate to the system store should make this reproducible.
@TheParanoidProgrammer thanks for investigating further. It is highly appreciated!
On a side note, it turns out that Ubuntu Maintainers ship gpg with GnuTLS dynamically linked, so that's why I went down that road first. I compiled gpg from source for Ubuntu with ntbtls for further tests. Interesting insight is that find_cert_bysubject returns different certificates on first try on my Ubuntu Machine compared to my Windows 10 Machine: