[Bug report] signingKey beying bypassed

Hello,

I have reasons to believe git isn't honoring the configured signingKey config on the .gitconfig.

the git-tag manpage states:

"
CONFIGURATION
	By default, git tag in sign-with-default mode (-s) will use your committer
	identity (of the form Your Name <your@email.address>) to find a key. If you
	want to use a different default key, you can specify it in the repository
	configuration as follows:

           [user]
               signingKey = <gpg-key-id>
"

I do have my $HOME/.gitconfig configured to always sign tags with a specific key per above documentation, and I just take it for granted. Today I had two smartcards connected, and when signing a tag, git-tag used the wrong key to sign the tag, instead of the specified in the .gitconfig.

I believe this might be a bug or some expected behavior that doesn't match the manpage. Or perhaps I misinterpreted the manpage?

- What did you expect to happen? (Expected behavior)

git-tag to sign a tag with the .gitconfig specified key or issue a warning it couldn't use it.

- What happened instead? (Actual behavior)

A tag has been signed with a key different than the one specified in the .gitconfig

I can reproduce it on any git repository in my machine, even a fresh just initiate repo.

[System Info]
git version:
git version 2.47.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
libcurl: 8.9.1
OpenSSL: OpenSSL 3.2.2 4 Jun 2024
zlib: 1.3.1.zlib-ng
compiler info: gnuc: 14.2
libc info: glibc: 2.40
$SHELL (typically, interactive shell): /bin/bash

No Enabled Hooks

Thanks Carlos

P.S. I'm not subscribed to the list, so, please Cc me on any reply.

On Fri, Dec 13, 2024, at 21:23, Carlos Maiolino wrote:

That’s the list policy.

On Fri, Dec 13, 2024 at 09:23:29PM +0100, Carlos Maiolino wrote:

No, I'd expect it to sign with the key that you configured. Two things I'd check:

  1. Try "git config --list --show-origin" to make sure you do not
     accidentally have incorrect config somewhere overriding what you
     expect.

  2. Try signing with "GIT_TRACE=1" set in the environment, which will
     show the gpg command we run. E.g.:

       $ GIT_TRACE=1 git -c user.signingkey=foobar tag -s -m foo bar
       [...]trace: built-in: git tag -s -m foo bar
       [...]trace: run_command: gpg --status-fd=2 -bsau foobar
       [...]trace: start_command: /usr/bin/gpg --status-fd=2 -bsau foobar

     If git is passing the correct "-u" option to gpg, then the bug (or
     misconfiguration) may be in gpg.

-Peff

On Mon, Dec 16, 2024 at 06:35:43AM -0500, Jeff King wrote:

Sorry the late reply Jeff... Holidays, family, the whole thing...

Ok, this returns the 'correct' key:

$ git config --list --show-origin|grep sign file:$HOME/.gitconfig user.signingkey=0C...

yet just creating a dummy tag on a dummy repo:

$ git tag --verify foo object 5d3928490fc1506afa0e0cfada15819e2eac922f type commit tag foo . . . gpg: using ECDSA key A6...

Hmm, this actually works. Doing this, the tag is signed with the key I pass on the CLI.

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.

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.

Cheers and happy new year

On Mon, Jan 06, 2025 at 03:55:32PM +0100, Carlos Maiolino wrote:

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?

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

Hi Jeff, sorry the delayed reply.

On Mon, Jan 06, 2025 at 10:00:25PM -0500, Jeff King wrote:

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.