# [Bug report] signingKey beying bypassed 6 messages from 2024-12-13 to 2025-01-13. Participants: Carlos Maiolino, Kristoffer Haugsbakk, Jeff King. Thread: https://gitlist.dev/t/62638 ## Carlos Maiolino, 2024-12-13 20:23 Subject: [Bug report] signingKey beying bypassed Message-ID: URL: https://gitlist.dev/e/hx6q4liyd7udyezlqy2fzanxlicu24imtdqielig622sdqz2wc%40lxa4ybnzyjs5 ``` 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 ) 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 = " 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. ``` ## Kristoffer Haugsbakk, 2024-12-15 12:26 Subject: Re: [Bug report] signingKey beying bypassed Message-ID: URL: https://gitlist.dev/e/b1cf4f03-1716-49fe-89ed-333c12ba4efe%40app.fastmail.com In-Reply-To: ``` On Fri, Dec 13, 2024, at 21:23, Carlos Maiolino wrote: > P.S. I'm not subscribed to the list, so, please Cc me on any reply. That’s the list policy. -- Kristoffer Haugsbakk ``` ## Jeff King, 2024-12-16 11:35 Subject: Re: [Bug report] signingKey beying bypassed Message-ID: <20241216113543.GD2201417@coredump.intra.peff.net> URL: https://gitlist.dev/e/20241216113543.GD2201417%40coredump.intra.peff.net In-Reply-To: ``` On Fri, Dec 13, 2024 at 09:23:29PM +0100, Carlos Maiolino wrote: > 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 ) 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 = > " > > > 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? 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 ``` ## Carlos Maiolino, 2025-01-06 14:55 Subject: Re: [Bug report] signingKey beying bypassed Message-ID: URL: https://gitlist.dev/e/cw6ggzhw4o5c5v5juh7sx2ubfaidnzugxx3ydgfvdlywqhndzf%406rfdfajvscif In-Reply-To: <20241216113543.GD2201417@coredump.intra.peff.net> ``` On Mon, Dec 16, 2024 at 06:35:43AM -0500, Jeff King wrote: > On Fri, Dec 13, 2024 at 09:23:29PM +0100, Carlos Maiolino wrote: > Sorry the late reply Jeff... Holidays, family, the whole thing... > > 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 ) 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 = > > " > > > > > > 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? > > 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. 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... > > 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 Hmm, this actually works. Doing this, the tag is signed with the key I pass on the CLI. > > 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. 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 > > -Peff ``` ## Jeff King, 2025-01-07 03:00 Subject: Re: [Bug report] signingKey beying bypassed Message-ID: <20250107030025.GA21698@coredump.intra.peff.net> URL: https://gitlist.dev/e/20250107030025.GA21698%40coredump.intra.peff.net In-Reply-To: ``` 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 ``` ## Carlos Maiolino, 2025-01-13 09:05 Subject: Re: [Bug report] signingKey beying bypassed Message-ID: <47yfez6r4f4jitps3re23q5vp6vzjas5624f2mp3looocc2myg@vineab4jdxdl> URL: https://gitlist.dev/e/47yfez6r4f4jitps3re23q5vp6vzjas5624f2mp3looocc2myg%40vineab4jdxdl In-Reply-To: <20250107030025.GA21698@coredump.intra.peff.net> ``` 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 ```