Will be in 2.2.29.

We need to see how to best fix this regression test for all Python versions.

FWIW: We have always refused to support shared mode because we anticipated such problems. However, we have a customer using their own cards along with card maintenance software of them. For their purposes PCSC_SHARED works just fine makes and this is why I decided to add --pcsc-shared along with a warning that it is in general not a good idea.

You need to protect only 2 critical set of ADPU sequence Sign and Decrypt. All other can be done not safely and have a minor impact. Get generation and cards unlock can be profitable with the transaction mode... but is very rare user makes another use of the card in same time he start that’s command. The check external interference can protect from a bad start. I have started this ticket because my card suffer in exclusive mode render the use of openpgp not really usable. When my card is an pcsc-shared mode, all it's OK but the daemon not able to restore after external interference. The correction proposed is OK but I have made recommendations because this can cause a bad applet switch... if the state does not restore before trying to switch applet all it's OK. I am not actually able to set directly differential code but I have described in the patch the change I have made and this make my card very happy. Not problems and the pin was queried if another application makes interference.

There are multiple issues here.

Thanks werner. That helps us to know that such test failure is not a deep issue that would push us to not deliver this version of gnupg on AIX.

Setting the gpg.program configuration value to "C:\\Program Files (x86)\\GnuPG\\bin\\gpg.exe" appears to resolve the issue.

It appears that Git ships with its own GnuPG program set, as can be seen in the attached image. I'll attempt to set the gpg.program setting in Git and see if that helps.

That looks all fine.

With the next release you will get only a warning:

gnupg-2.2/common/t-sexputil.c:467: test 0 failed: Unknown elliptic curve - ignored
This is likely due to a patched version of Libgcrypt with removed support for Brainpool curves

The only download I have executed with regard to gpg4win is from the gpg4win website. You can see the output of the command you specified below.

may give you some clues.

You are not using gpg4win with its included GnuPG 2.2 but some broken gpg version. The error message
"invalid size of lockfile" can only be emitted by the Unix version of GnuPG. Check for other installed gpg versions - there are sites which allows the download of for example a Cygwin version - these version can't work properly on Windows.

I did some test on Windows 10 using gnupg 2.2 with this patch and things work.

For testing ion Windows 10 you need to switch to "Legacy Console" and reboot.

I think that a patch like following is needed:

diff --git a/common/ttyio.c b/common/ttyio.c
index c385700de..55468bdf0 100644
--- a/common/ttyio.c
+++ b/common/ttyio.c
@@ -236,7 +236,21 @@ w32_write_console (const char *string)
   n = wcslen (wstring);

When console font is not a Unicode font, it seems that the WriteConsoleW function may return ERROR_GEN_FAILURE.

Hello Mr. Koch,

Sorry for the expired certificate.

Fix: "I Know so few about gnupg, thus I'm not sure I COULD add test cases, probably not. "

Hi,
The site now shows: "NET::ERR_CERT_DATE_INVALID" and I have a limited access to the web page.
Thanks for you explanation. However, I now so few about gnupg, thus I'm not sure I cannot add test cases, probably not. I'll see later if we have to provide on AIX a behavior different than the one of RedHat. Meanwhile, about your last proposal, yes it would be very useful to detect the case, print a warning, and skip the test. That would be helpful. Moreover, if the test deals with smartcards, we do not have on AIX, thus this test is very probably not useful in our environment.

Please run

The thing is that I added a test for a new function which uses standard curves of Libgcrypt. But here we are again at the RedHat mess: They support the NIST curves but they removed support for Brainpool curves. Both are very similiar curves just different parameters. Brainpool is just in Europe out of fear that the NIST curves are rigged by the the NSA. Now, why RedHat removed Brainpool is probably just a legal dept thing who didn't have a clue. The tin foil hats probably see a different reason.

• a patch change within scd/apdu.c dealing with a call of: pcsc_connect() since code has changed between the 2 versions: may this be the cause of the failure? (Edited: hummm this patch seems no more required. And I have the same failure without it).

Hi Werner,

Supported curves should be listed by

gpg --list-config --with-colons curve

I am not sure about Fedora, but RedHat used to remove ECC support from Libgcrypt; GnuPG requires these curves. As long as you don't use ECC you things will work despite of this failed test. The test is new to check and does not anticipate a broken Libgcrypt.

Replicated and fixed. Thanks for the report.

In fact, the trigger is not yubikey but the pcsc-shared flag... If the pcsc-shared flag is enabled, you do check for interference because you are in shared condition. It is not really a race condition because you can put the driver in transaction mode. It’s more a turn-by-turn games but you can lose the card context status between turn.
If you lock the patch only for yubikey I’m not able to test with my device. You can add my manufacturer ID in the test please.

Thank you for your explanation.

Thank you for your report.
I pushed the fix.

It's not a device is a card. NXP P71 security chips on the card in the 250Kb Rom with GlobalPlateform 2.1.1 It is not possible for a card to change CCID by applet. Card depends of reader CCID. When the card is on NFC readers, the FIDO applet is accessible not when it is on contact readers. But, when I am in NFC FIDO share the CCID. For the user point of view having multiple card for each applet is a bad thing to devices for one user. User search presently for multipurpose devices. DOOR, Login, Email-crypt, ledger. Actually for app is not recommended to use a reader in exclusive mode. By designs the card is stateless and for memory management deselect applet free mem from other applet. Presently in the best case the card has 144-255 KB of eeprom and 2k or ram.

If your token/card is not Yubikey and when it is possible to improve your token/card implementation, I would suggest not follow what Yubikey does for multiple applications; No multiple applications, but each feature with independent access (card+CCID, another card+different CCID, FIDO+HID, ...).

i'am not able to test... i can't build for win32. i have some trouble with my mingw32 installation and the miss match with library for build a functional version of gnupg for win32.
seem missing dll after make install folder. do you have instruction to setup dev environment for build win32 binary ? I use a ubuntu with minwg32. ntbtls seem missing ksba but libksba is already install verion 1.6.0 other project detect correctly ksba. it's seem is a little bit complicated juste for building scd project. a make it working correctly on windows environements.

The problem has been solved by me, but this and the problem are still very strange.

Ok i have seen a problem with a double check here

Ok, I test this, this seem can be corrected 90% of all possible interference with another application on multi-applet smartcard in shared readers context. I left you the feel back when have tested… thank for the prompt response.

For the problem of external application switch, please test this:

diff --git a/scd/app-common.h b/scd/app-common.h
index dffe1200d..d6e6f4c0a 100644
--- a/scd/app-common.h
+++ b/scd/app-common.h
@@ -194,6 +194,8 @@ struct app_ctx_s {
                       void *pincb_arg);
     gpg_error_t (*with_keygrip) (app_t app, ctrl_t ctrl, int action,
                                  const char *keygrip_str, int capability);
+    gpg_error_t (*check_aid) (app_t app, ctrl_t ctrl,
+                              const unsigned char *aid, size_t aidlen);
   } fnc;
 };

Here is the reference to GID specification:
https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn642100(v=vs.85)?redirectedfrom=MSDN

Let me add the tag "yubikey".
I think that it could be solved in different level, if I were the device manufacturer; And it would give users the best solution.

Hello Mr. Koch,

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.

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?

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.

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?

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

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.

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

Thanks. Commited as rG755a5f1a0e3

Thank you Werner for fixing this! We just came across the group permission issue in a multi-user environment and all we had to do was to upgrade to gnupg >=2.2.24.