Yes, I removed them accidentally because they were listed under the keyserver option heading in gpg. They actually belong below the import/export heading.

Looks good. After entering a wrong passphrase three times Kleopatra now reports

Moving the key to the card failed: Bad passphrase

With my patch I see the expected status message:

The problem seems to be that we don't return a status code with the
actual error via the --command-fd interface:

New release of libassuan is expected to make sure it's cleared off.

Probably fixed meanwhile in 2.2.
Please re-open if experience this problem also with a decent gnupg 2.2 versions.

The fix has been merged to the 2.2 branch.

In T6067#160368, @vitusb wrote:

Due to https://dev.gnupg.org/T5725#153224 ("The fingerprints are needed by Kleopatra as unique identifier for keys."), is this still implemented in that way ?

What i don't understand is ...

It will hopefully be fixed in 2.2.37.

Hello,
thanx for fixing this issue ...

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.