On Mon, Jan 06, 2025 at 03:55:32PM +0100, Carlos Maiolino wrote: > > If git is passing the correct "-u" option to gpg, then the bug (or > > misconfiguration) may be in gpg. > > I particularly think git is the 'problem' here. After I tried GIT_TRACE, I decided > to run it without specifying the key on the CLI as I'd normally do, and it did > work normally, and I think I what happens is git defaults for another key, if > the specified key is not available. Git doesn't know anything about available keys, though. We just call "gpg" with the signing key configured in your .gitconfig and it tells us whether it worked or not. Are you saying that: GIT_TRACE=1 git tag -sm foo foo shows git invoking gpg with the wrong key, but: GIT_TRACE=1 git -c user.signingkey=$RIGHT_KEY -sm foo foo uses the right key? That implies something funny with the config reading. Or are there cases where GIT_TRACE shows us passing the right key to gpg, but the signature is made with the wrong key? Then that is not something git can control, and is a problem with gpg. Can you show us the exact commands you're running and their output? > As I mentioned earlier, the key configured on my .gitconfig, is inside a > smartcard. > I just tested creating a tag, without the smartcard connected, and git > ignored the signing key I passed, using another key. > > I am not sure how right I am, so please correct me if I'm not, but I would > expect git tag to fail, or at least give me a big warning if for any reason it > could not sign the tag with the specified key. I'd expect it to produce a warning, too, but we can only do so if gpg tells us it failed. From Git's perspective, we are just passing along the key string from user.signingkey to gpg. We don't know what it means, and don't have any mechanism for using a different key. -Peff
