The patch applies with -p1 to the master brach, alternatively I could push a commit, but my user does not seam to be allowed to do so:

[Merging didn't work]

Attached you find a patch to this issue. This Patch sets the "keypair" attribute to the keys 0x82 to 0x95 unconditionaly.

In T6218#163787, @gouttegd wrote:

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

Yes. Scute relies on those to interact with the token.

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

That sounds quite cool.

Actually we developed PIV support to allow the use of PIV X.509 certificates and OpenPGP keys with Yubikeys. In fact, GnuPG is able to switch between the Yubikey PIV and OpenPGP applications on-the-fly while keeping their PIN verification states.

I was indeed using version 1.5.0 for testing, but I wish to clarify the purpose of Scute in my setup before proceeding.

Which version of Scute are you using?

Using Scute as a drop-in replacement doesn't currently work. Perhaps my config needs more adjustments than just:

module = /usr/lib/x86_64-linux-gnu/scute/scute.so

Yes, I meant to use Scute as pkcsc11 module for pam_pkcs11. Thanks for explaining more verbosely what I meant.

I think Werner may have confused pam_pkcs11 with gnupg-pkcs11-scd. :)

I'm not sure what you mean with using Scute as PKCS#11 provider instead of pam_pkcs11, as pam_pkcs11 is not a provider but a user of PKCS#11

There is a reason why pcsc-shared is not the default ;-). Please try using Scute (best the t6002 branch until it has been merged) as pkcs#11 provider instead of pam_pkcs11. And you should of course use the stable version of GnuPG and not the LTS (2.2).

Testing gpg-auth : There are two different use cases

• test with xsecurelock for screen lock
• test with pam-autoproto for login / gdm / etc.

Here are pam_authproto.c with Makefile, so that you can compile it with libpam:

Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.

Needs to be forward ported to master

The delays are due to /usr/sbin/laptop_mode from the laptop-mode-tools package.

Inserting as well as removal is detected on my machine always only after 25 seconds

I wrote a simple testusb.c if monitoring USB devices works:

#include <stdlib.h>
#include <libusb.h>
#include <poll.h>
#include <stdio.h>

exact v.2.3.8 is expected, generally I don't import Key on yubico I generate them directly from yubico itself in order to have the private Key created directly on yubico and not exportable.

Hi! I would like to add my experience about this issue.

what's new for a possible gnupg 2.3.8 or gpg4win 4.0.4 release?

Here is an example

If the stub has been created or updated we will now ask for the card
with the Display-SN. If in addition a Label has been set to the key
that label is also shown. Note that the Display-S/N is associated wit
a card but the Label is associated with a key. For example if the
same key has been stored on two cards, the prompt will ask for one of
those cards but shows the same same Label. It is sufficient to insert
any of the cards with the key because that is what we actually need.

In master we already have Token lines which are created but not yet used. I am going to extend this with the display S/N and drop the idea of a separate Display-SN entry.

I am going to introduce a new DisplaySN: value for 2.2 which might also be useful for master.

We have changes for this in master; I need to see whether it is possible to backport them.

While playing with your scripts I figured that it would be useful to enhance the KEYINFO command. With
rG989eae648c8f3d2196517e8fc9cce247b21f9629 we could now

@gniibe Perfect, I got the update during the night actually. Thanks a lot for your work 🙏 .

For the firmware 5.4.3, I confirmed that it works well with the changes:
https://dev.gnupg.org/T6070#160150

Hi lovely people,

I have exactly this problem with yubikey here,
since i upgraded to gpg4win version 4.0.3 which contains gnupg 2.3.7 i get the same error as openpgp key not recognized.

@tigernero 2.3.8 is not yet released. Pretty sure gpg4win is a separate project, presumably you'll see a changelog entry here (as there is bumping to 2.3.7 in the latest 4.0.3) when it's in:
https://www.gpg4win.org/change-history.html
https://www.gpg4win.org/support.html

I can't find a url to download gnupg 2.3.8 for windows is it possible to know when gpg4win v.4.0.4 is out which fixes this bug? because currently on windows systems I am stuck using yubikey.

Fixed quite some time ago.

I just confirmed that firmware 5.4.3 works fine with the changes (to be 2.2.37 and 2.3.8).

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

Does Yubico furnish you with devices for test...

Thanks @gniibe. Does Yubico furnish you with devices for test, or did you have to order that at your own/the project's expense?

I'm going to backport this to 2.2, as it found useful.

And 2.3.7.

Fixed in 2.2.36.

It's in 2.3.7.

It's in 2.3.7.

It's in 2.3.7.

It's in 2.3.7.

Having "Use-for-ssh" flag now, experience shows that including OpenPGP.3 keys by default is not convenient.

Backported to GnuPG 2.2.

Now, it also supports a reader with pinpad.

Updated (with T6012):

See https://github.com/google/xsecurelock/blob/master/helpers/authproto.h
for the interaction between xsecurelock and the helper.

I changed gpg-connect-agent (added --unbuffered option) so that we can write shell script interacting gpg-agent.

Wrote a shell script for xsecurelock's authproto (helper executable):

Related problem exists with the modern ESIGN application. I think I fixed that but the whole Telesec eIDAS QES case needs more work.