signing a git commit keeps lock on yubikey 5

[n0xena]

So, after I got my YubiKey and played around with it a lot, I tried to use it for both git commit signing as well as git ssh access and stumbled upon an issue that I thought to have already fixed.
When playing around with GnuPG, YK-man and yubico-piv-tool I noticed that in some combinations the access to the key will get stuck. To most this seems to be an issue with the GnuPG internal CCID SC-daemon. A solution to that: add disabled-ccid to ~/.gnupg/scdaemon.conf - and that works.
When I played with git commits and git ssh I encountered the same issue yet again although the config is set.
I also had to use a work-around as using PIV keys doesn't seem to work with ssh-agent well, too.

Here's my workflow:

GIT_SSH_COMMAND="ssh -I /usr/bin/libykcs11.so" git clone/pull ssh://git@github.com/<user>/<repo>
// doing some stuff
git commit -S -m "<commit message>"
// this is when git keeps the lock on the key - so workaround:
gpg-card
> reset
> quit
GIT_SSH_COMMAND="ssh -I /usr/bin/libykcs11.so" git push ssh://git@github.com/<user>/<repo>

So I have two issues:

1. using ssh-agent doesn't want to work properly
   Adding the key works - I get asked for the pin. But every next ssh operation causes a fail with some errors like ssh-pkcs11-helper[120253]: error: need pin entry - so the ssh-agent doesn't seem to be able to use the added PIV keys
2. when signing a commit although disable-ccid is set in scdaemon.conf it still keeps clinging onto the key until it gets reset

I'm still learning and experimenting - but isn't the whole idea behind the yubikey (or any HSM-like token) and its features to a) not have any private keys on-disk but safely on the key and b) don't have to deal with all the quirks of these different eco-systems (gnupg, ssh, git) but it should "just work"?

I'm up for a challenge (I even tried to use my fTPM - but that failed for other reasons - if someone wants to read about it: https://github.com/n0xena/trust-root/blob/main/draft.md) - but with a product already in its 5th iteration and nearly 20 years of experience I somewhat expect these issues to fixed some time ago.

I know doing your own crypto right is hard - hence hobbyists like me should rely on experts like you - but these kind of issues are something I expect to be caught in development.

If it's relevant for anyone: I'm using vanilla Arch Linux with mostly only the official repos - although I'm no stranger to the AUR. I've not yet tested to reproduce this on other distributions or windows - but I guess it highly depends if git (or what ever sub-command it calls) properly releases the key after signing. If git just calls gpg internal then this should already be the case by the config as gpg itself works without issues.

[n0xena]

I played around a bit more, reset the key and created new keys with all security disabled (pin, touch) - and got the next caveat:
When the key is loaded via ssh-add -s /usr/lib/libykcs11.so gnupg is blocked so it can't be used for signing.
That's quite a bummer: So using different keys for the sake of seperation of concerns doesn't work because both workflows require exclusive access.
What's the solution then? Use pgp for both signing and ssh authentication with gpg --export-ssh-key?
I also tried adding enable-ssh-support to gpg-agent.conf and set SSH_AUTH_SOCKET to $XDG_RUNTIME_DIR/gnupg/S.gpg-agent.ssh - but this breaks my regular config by overriding the regular IdentityFile - so I have to modify all my other servers to now also use the YubiKey - which I don't want to.

[n0xena]

I narrowed it down to gnupg itself keep holding a lock both when using its own scdaemon as well as pcscd.
Unfortunately I'm not able to report this to the gnupg mailing list as I only get bounces. Checking my domain and server I'm on no blacklists. So, would be nice if someone of you could try to contact gnupg dev list about this - as I can't.

[n0xena]

dug deeper - https://forum.gnupg.org/t/gnupg-keeps-lock-on-yubikey/6826
to me this is a bug of gnupg: it grabs the key by lazy init - and never releases it - gonna file a bug report