Hi Jeff, sorry the delayed reply. On Mon, Jan 06, 2025 at 10:00:25PM -0500, Jeff King wrote: > 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. First, I'd like to apologize because I'm not exactly sure if what I'm doing is correct, and exploring it a bit, I do agree with you this smells more a gnupg problem after the information you provided. I was just playing around with it a bit. And I can't really understand gpg's behavior here. As you asked, here is what I'm doing now: - I commented out the user.signingkey in my .config file, and I'm specifying it on the CLI as you suggested. I have a subkey stored locally (besides the one in my smartcard). So, I tried to use the locally stored key to create a new signed tag, in a random repo, with this command: $GIT_TRACE=1 git -c user.signingkey=A6... tag -s foo -m "bar" First thing gnupg does is ask me to provide my smartcard passphrase, even tough my smartcard is not even connected :) After I cancel the password request (I use pinentry, so it moves to the pwd prompt), I can see the trace: 09:29:49.780058 git.c:479 trace: built-in: git tag -s foo -m bar 09:29:49.781317 run-command.c:666 trace: run_command: gpg --status-fd=2 -bsau A6... 09:29:49.781361 run-command.c:758 trace: start_command: /usr/bin/gpg --status-fd=2 -bsau A6... error: gpg failed to sign the data: [GNUPG:] KEY_CONSIDERED 40... 0 [GNUPG:] BEGIN_SIGNING H9 [GNUPG:] PINENTRY_LAUNCHED 5587 curses 1.3.1-unknown /dev/pts/5 xterm-256color :0 20620/1000/5 1000/1000 0 gpg: signing failed: Operation cancelled [GNUPG:] FAILURE sign 83886179 gpg: signing failed: Operation cancelled So, from my POV, git is passing the correct key to the gpg commandline, but for whatever reason gpg is ignoring it. The key it defaults to, is the one in my smartcard. I'm not sure why it is using it as the default, I don't have any default key configured in my gpg. When I cancel the pwd request for the key, gpg emits the KEY_CONSIDERED message, with yet a different key, and fails the operation. Well, anyway, thanks for the help, but I do think now git is only a victim here of some weird behavior from gpg. I'll try to find out more information about this. > -Peff
