This works if the smartcard with the same private key is not connected, which it usually shouldn't be (outside of testing situations) so that's ok for me.
But I think we should inform the user what is done or isn't.
Currently we get in both cases:

gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 1
gpg:              gelesene geheime Schlüssel: 1
gpg:            geheime Schlüssel importiert: 1

Which is not very clear in any case but in case the smart card is connected it is in fact wrong, there is no secret key imported, the keystub remains.

Good timing. We have just added the necessary bits to the shared libkleopatra. They just need to be used in GpgOL. See T6330: Kleopatra: Additional Expiry handling.

Ready for testing.

Ok, so this is not an issue for a standard user. Still I think "wrong PIN" should be given on the command line, too, and not only in the debugfile output.

In T6466#169934, @werner wrote:

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.

A few remarks:

• For now the users are just informed about the upcoming expiration of certificates used in the Sign/Encrypt dialog. There is no button to act or get further information what to do about it.
• Expiration of issuer certificates are ignored. If a leaf certificate gets invalid as soon as any certificate in the issuer chain expires, then it may make more sense to treat this as expiration of the leaf certificate since that's effectively what happens. On the other hand, if the expiration of certificates in the issuer chain have no effect on the validity of the leaf certificate (because at the time the leaf certificate was certified the chain was valid), then, in my opinion, it makes little sense to bother the users with the expiration of chain certificates.
• I took over the default values that are also used by KMail and that seem to be the recommended default by SPHINX (according to the comments for the settings in KMail).
• I decided to save/load the thresholds from a shared configuration file (kleo-expirycheckerrc), but to keep the setting whether to show expiry notifications as per-application setting.

works, at least for Yubikeys and Zeitcontrol cards

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.

What it does (in g10/card-util.c:card_store_subkey) is:

if (rc)
  log_error (_("KEYTOCARD failed: %s\n"), gpg_strerror (rc));

Here's fix for mode specific setkey clearing error code:

The commit hashes are different:

• Here: 81a281183ff949fc88ef187118bbf3e89f4466ac (81a281183ff9)
• At GH: 35b9de6461762ff4849ebd7aa277f453b7f42be9 (35b9de6)

True, also because this works well when resolving a merge-conflict locally.

In Kleopatra an error window comes up in this case:

Kopieren des Schlüssels auf Karte fehlgeschlagen: 
Falsche PIN

There is still a buglet because in some modes the weak key error can be swallowed by other errors. A fix would be something like:

@jukivili Yes, please go ahead for both branches. Thank you.

I checked the upstream. For the reported issue, upstream version raises an error with REG_ERR_UNMATCHED_BRACKET.
That behavior is better (as we don't have particular reason to maintain different behavior from upstream version).
Also, I found another change from upstream for end of word check.

About error code. You need to use gcry_err_code(error_code) to get the GPG_ERR_WEAK_KEY value.

I wonder why github did not automatically closed this pull request - after all exact that patch was commited.

Commits & closes https://github.com/gpg/gnupg-doc/pull/2

Okay, that was easy to check.

Not easy to fix because gpg --card-edit/-status has some support form other cards. Eventually these commands will be replaced by gpg-card. In the meantime we can use this hack: