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.

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.

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.
I tested:

• GNU/Linux
  • i686
  • x86_64
• Windows
  • i686

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.

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).

Backported to GnuPG 2.2.

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.

Pushed the solution which doesn't require new flag for libassuan.

^-- I withdraw the solution (with error value) above.

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.

For this particular issue of assuan_inquire, if it's needed, the point we should fix is:

AFAICS, we need to implement a new Assuan flag and wipe the data passed to the callback after the callback returned.

I just wrote a blog article about this problem
https://ludovicrousseau.blogspot.com/2022/05/scardlistreaders-and-non-initialized.html

Thanks for opening a ticket.

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.

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.

it would be useful to add a test

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.

Was fixed in 2.3.5

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

Updated the copy on our mirror as welll as the gpg4win and swdb packages files.

The fix is from 2018 but was not picked up widely; see
https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531

Not applying the change to GnuPG 2.2, users can use GnuPG 2.3 for that.

Merged into T5804.

Thank you. Confirmed.

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

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.

I think that this commit rG8fd150b05b74: gpg: Remove all support for v3 keys and always create v4-signatures. matters.

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”.

Great, thank you very much!

Thanks for notifying. Will be fixed in the next release (mid Apri).

Fixed in master and 2.2 branch.

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

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.

In T5639#155478, @werner wrote:

echo BYE | dirmngr -vv --server 2>certs.log

Lists all certificates

@TheParanoidProgrammer this looks like a very good and thorough analysis, thanks again!

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: