It runs like:

$ gpg-connect-agent "scd devinfo --watch" /bye
S DEVINFO_START
S DEVINFO_END
S DEVINFO_STATUS new
S DEVINFO_START
S DEVICE generic D276000124010200F517000000010000 openpgp
S DEVINFO_END
S DEVINFO_STATUS removal
S DEVINFO_START
S DEVINFO_END
OK
$ 

Push the change to master.

The return value that was mapped to invalid value was "SW_WRONG_LENGTH" so I tested using the codepath for the SW_EXACT_LENGTH sw return value, too and it worked for readcert.

Created https://dev.gnupg.org/source/gnupg/history/gniibe%252Fscd-watch/

Backported to 2.2

I pushed the change to master.

Fixed in master.

I would prefer to have a procedure that do not reset PINs to their default values, but as long as all PINs are set to known and valid values when KDF is setup it will not make the token unusable after that, so it seems reasonable to me.

Or, #5 would be:

@Amaud, I read your code in Python. IIUC, it asks users PW1, Reset Code, and PW3 to setup, just before registering KDF DO (as you describe in https://dev.gnupg.org/T3891#114950).

Thanks for concrete cases. Sorry, not responding earlier. It was an experimental feature, firstly only available in Gnuk Token.

I implemented the script described previsouly (https://dev.gnupg.org/T3891#114950) in the smartpgp-cli utility provided in the SmartPGP repository (see commit https://github.com/ANSSI-FR/SmartPGP/commit/4be0fa442b43c2bafd5f0171417ff68fd88cbe2d).

Some users of ours wanted to use KDF with their OpenPGP smart cards. Could you tell when solution to this issue could be expected?
Additionally, is there any workaround for the current state? Perhaps based on T3823, or on derived [1]? To which values the PINs had to be set?

There is no use cases for $SIGNKEYID.

$ENCRKEYID use case have been removed.

Caching of the OpenPGP PIN while switching to and from PIV does now work in master

$AUTHKEYID use cases have been removed.