That patch consists an ABI change. We might consider this for 1.10 but we can't do such a change in 1.9.

Please try the distributed binary version of gpgme from GnuPG or Gpg4win (which is usually a snapshot). As you might now, we don't support building on Windows - it may or may not work, we have no idea and don't suggest that.

Are you using Powershell or another non-standard shell? Which windows version are you using? Do you use default-key in gpg.conf? Do you have a smartcard inserted?

If something more user friendly is required, it could be possible for higher layer (SCDaemon's command handling) to check verification status beforehand, and do error recovery there.

I don't think we should do automatic error recovery from 6982 to retry decryption/signing, inside CMD_PSO (0x2A) operation.

Thanks for the report. Will soon be fixed.

I have tried the case 1 with log activated
Windows switches applet for signing Adobe Acrobat doc.
This is the log from agent - Say Bad NIP but he never tries to use the nip SCDaemon have tried to decrypt only.
gpg-agent[8496]: DBG: agent_put_cache '1//'.-1 (mode 6) requested ttl=-1
gpg-agent[8496]: DBG: chan_0x000001c0 <- S SERIALNO D2760001240103045343000000010000
gpg-agent[8496]: DBG: chan_0x000001c0 <- OK
gpg-agent[8496]: DBG: chan_0x000001c0 -> KEYINFO BBD342CA5B0F978DA17F2AD9F5A1E95FF50C129E
gpg-agent[8496]: DBG: chan_0x000001c0 <- S KEYINFO BBD342CA5B0F978DA17F2AD9F5A1E95FF50C129E T D2760001240103045343000000010000 OPENPGP.2
gpg-agent[8496]: DBG: chan_0x000001c0 <- OK
gpg-agent[8496]: DBG: chan_0x000001c0 -> SETDATA 4F0E7600C2C497A06288DF49B7EA1BC723E04FAC360D6D6C4F4DC1B48DEC13A53556229CDC4562E349C9B5E71365561A941761D1D2C709A16488903AA60925A7B103DEF6B6AE46814370AE815BFBE4A30EC443904C1D63E21ABF5B0B39B8484F3CB4235AEDA04F78F14308AE3DEF52309FB745BC65E3075D19C01C789C8F58931D957D7C26BE7DCEF6B880B362251246FA4E1A2830A13AD94635CC4CE14B0F253481F38C39BA5CC748FDF03F9D936B9C8DE6BF7E49AFF4BE3A84A4E4547FADD4C9F1634416641FF804F3503CC924098F1C4CAA908FD272737312A4D5BE59C644EE1633AA248DC996EF67BA5E087DB6312BD2014BFAFD62FD08C7D45E3AFD431C
gpg-agent[8496]: DBG: chan_0x000001c0 <- OK
gpg-agent[8496]: DBG: chan_0x000001c0 -> PKDECRYPT BBD342CA5B0F978DA17F2AD9F5A1E95FF50C129E
gpg-agent[8496]: DBG: chan_0x000001c0 <- ERR 100663383 Mauvais code personnel <SCD>
gpg-agent[8496]: smartcard decryption failed: Mauvais code personnel
gpg-agent[8496]: command 'PKDECRYPT' failed: Mauvais code personnel <SCD>
gpg-agent[8496]: DBG: chan_0x00000270 -> ERR 100663383 Mauvais code personnel <SCD>

Thank you.

Thank you.
I apply Diff1487 then Diff1488.

Let me explain this problem more clearly. GPGME did not correctly receive and parse the output from gpgconf. Looking at the log file, EOF was generated when 4096 bits were read. So in engine info, although the path is correct, the identification of the version number is 1.0.0, and there is only gpgconf in the protocol, but there are no protocols such as gpg, assume, etc., which just means that gpgme does not correctly identify the output of gpgconf in this environment Information to find other protocols.
At the same time, I verified whether the output in gpgconf and the path of the related configuration are correct (whether there is a corresponding tool under the path), these are all right, which is very strange.

When a card sends 0x6982 in general rule is not really an error is a warning to say, your security environment was not correctly initialized.
This is true with almost applet. (PIV – GIDS – OPenPGP)
The instruction 0x2A to perform security operation return 0x6982 when pin is not authenticated or key is badly selected. This not decrement pin counter.

This is the log file output after the GPGME DEBUG environment variable is set.

You should run your test program with GPGME_DEBUG set. This gives some insight. The code you posted is too sparse to actually see what you are doing or want to do or what is the bug. Maybe it is better to ask the gnupg-devel ML?

Some ideas:

• the someflags thing will probably just be a reserved parameter
• If DATA is not NULL but an MD is set the sign function should fail
• Should ownership of MD be moved to the CTX?

In an email from @werner couple days back, I got a suggestion that we could use hashing tied to the context, rather than this one-shot call tied only to digests. I circled back this suggestion to Stephan and he confirmed that it should be fine from the FIPS point of view so I am posting the suggested API here too:

ctx = gcry_pk_new (someflags)
md = gcry_md_open (...)
gcry_ctx_set_md (md);
gcry_pk_sign_ext (ctx, result, data, skey)
[...]
gcry_ctx_release (ctx);

OK. I think that the patch at SUSE is updated one which works.
As I understand correctly, this is a kind of very old patch, which intended to work around old libgcrypt limitation of RSA PSS.

Possible way would be: (for newer card/token of OpenPGPcard 3.4 or later) before crypto operations, we can ask card/token if authentication state is consistent to the one of scdaemon and if not reselect AID.

CC does not offer such an option as the GPL does.

I'd like to support your use case. Could you please tell me about: How can we distinguish normal failure of 6982 and unusual failure of other application interference which results 6982?

I think that {D1476} is still a sketch (not real code which works). I would guess an intended use, but it's good to have concrete example program which uses the feature being added.

FWIW, there is also this newer patch: https://dev.gnupg.org/differential/diff/1476/
and SUSE seems to already use a modified API:
https://sources.suse.com/SUSE:Maintenance:15118/libgcrypt.SUSE_SLE-15_Update/26a8df5f96d27d6abca7bd7ba9b0def0/libgcrypt-FIPS-RSA-DSA-ECDSA-hashing-operation.patch

update

Our public key functions are stateless. For several reasons it would be good to have an option to keep some state (think pre-computations). Our gcry_ctx_t would be a perfect fit for this and it will allow us to join a pubkey function with for example a hash function.

Does the patch really work, or is it a sketch to describe the intended use?

@FloorVeil thanks for testing!

There is another report that it works in 3.1.16 again in
https://wald.intevation.org/forum/forum.php?thread_id=2044&forum_id=84&group_id=11

Not reproduced on 3.1.16.

I set the priority 'High' as Yubikey NEO is the last one with source code available, IIUC.

@kianga
Thanks for your log.

I was just about to open a similar bug report, but I think this might be related. I’m also having trouble getting my Yubikey NEO to work with the latest update, however my log output looks different (see below) and this is on Windows (10 Pro, 21H1, build 19043.1055).

Thank you @werner I will apply the patch and recompile the .28 version for myself.

Fix will eventually go into 2.2.29. If there is enough public demand we will do a new Windows installer earlier.

Regression Yubikey NEO: T5487

Thank you. Here are my comments.

Hi, I updated the whole file, PLZ review. https://dev.gnupg.org/D533

I think that Yubikey NEO is older than Yubikey 4.

Fixed in rG01a413d5235f: scd: Error code map fix for older Yubikey..
New code for Yubikey 4 or later causes wrong interaction for Yubikey NEO in 2.2.28.

Thank you for your report.

Thank you for your suggestion and making a patch.

Check out https://gnupg.org

But where i can find miling list ? I need get back my pgp key, because it's
now bock.

Sorry, I think, it is more official to update from 把密钥导出到一个公钥服务器上 to 将密钥导出到一个公钥服务器上 in the Chinese doc scenario. 😄😄😄😄

Thanks. Commited as rG755a5f1a0e3