{"thread":{"id":"62638","subject":"[Bug report] signingKey beying bypassed","startedAt":"2024-12-13T20:23:33Z","lastAt":"2025-01-13T09:05:51Z","messageCount":6,"participants":["Carlos Maiolino","Kristoffer Haugsbakk","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"509115","messageId":"hx6q4liyd7udyezlqy2fzanxlicu24imtdqielig622sdqz2wc@lxa4ybnzyjs5","threadId":"62638","inReplyTo":null,"subject":"[Bug report] signingKey beying bypassed","fromName":"Carlos Maiolino","fromEmail":"cem@kernel.org","sentAt":"2024-12-13T20:23:29Z","receivedAt":"2024-12-13T20:23:33Z","isPatch":false,"sender":{"key":"cem@kernel.org","avatar":null},"body":"Hello,\n\nI have reasons to believe git isn't honoring the configured signingKey config\non the .gitconfig.\n\nthe git-tag manpage states:\n\n\"\nCONFIGURATION\n\tBy default, git tag in sign-with-default mode (-s) will use your committer\n\tidentity (of the form Your Name <your@email.address>) to find a key. If you\n\twant to use a different default key, you can specify it in the repository\n\tconfiguration as follows:\n\n           [user]\n               signingKey = <gpg-key-id>\n\"\n\n\nI do have my $HOME/.gitconfig configured to always sign tags with a specific key\nper above documentation, and I just take it for granted.\nToday I had two smartcards connected, and when signing a tag, git-tag used the\nwrong key to sign the tag, instead of the specified in the .gitconfig.\n\nI believe this might be a bug or some expected behavior that doesn't match the\nmanpage. Or perhaps I misinterpreted the manpage?\n\n\n- What did you expect to happen? (Expected behavior)\n\ngit-tag to sign a tag with the .gitconfig specified key or issue a warning it\ncouldn't use it.\n\n- What happened instead? (Actual behavior)\n\nA tag has been signed with a key different than the one specified in the\n.gitconfig\n\n\nI can reproduce it on any git repository in my machine, even a fresh just\ninitiate repo.\n\n[System Info]\ngit version:\ngit version 2.47.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nlibcurl: 8.9.1\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\nzlib: 1.3.1.zlib-ng\ncompiler info: gnuc: 14.2\nlibc info: glibc: 2.40\n$SHELL (typically, interactive shell): /bin/bash\n\nNo Enabled Hooks\n\n\nThanks\nCarlos\n\nP.S. I'm not subscribed to the list, so, please Cc me on any reply.\n"},{"id":"509124","messageId":"b1cf4f03-1716-49fe-89ed-333c12ba4efe@app.fastmail.com","threadId":"62638","inReplyTo":"hx6q4liyd7udyezlqy2fzanxlicu24imtdqielig622sdqz2wc@lxa4ybnzyjs5","subject":"Re: [Bug report] signingKey beying bypassed","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2024-12-15T12:26:56Z","receivedAt":"2024-12-15T12:27:17Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Fri, Dec 13, 2024, at 21:23, Carlos Maiolino wrote:\n> P.S. I'm not subscribed to the list, so, please Cc me on any reply.\n\nThat’s the list policy.\n\n-- \nKristoffer Haugsbakk\n\n"},{"id":"509153","messageId":"20241216113543.GD2201417@coredump.intra.peff.net","threadId":"62638","inReplyTo":"hx6q4liyd7udyezlqy2fzanxlicu24imtdqielig622sdqz2wc@lxa4ybnzyjs5","subject":"Re: [Bug report] signingKey beying bypassed","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-12-16T11:35:43Z","receivedAt":"2024-12-16T11:35:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 13, 2024 at 09:23:29PM +0100, Carlos Maiolino wrote:\n\n> the git-tag manpage states:\n> \n> \"\n> CONFIGURATION\n> \tBy default, git tag in sign-with-default mode (-s) will use your committer\n> \tidentity (of the form Your Name <your@email.address>) to find a key. If you\n> \twant to use a different default key, you can specify it in the repository\n> \tconfiguration as follows:\n> \n>            [user]\n>                signingKey = <gpg-key-id>\n> \"\n> \n> \n> I do have my $HOME/.gitconfig configured to always sign tags with a specific key\n> per above documentation, and I just take it for granted.\n> Today I had two smartcards connected, and when signing a tag, git-tag used the\n> wrong key to sign the tag, instead of the specified in the .gitconfig.\n> \n> I believe this might be a bug or some expected behavior that doesn't match the\n> manpage. Or perhaps I misinterpreted the manpage?\n\nNo, I'd expect it to sign with the key that you configured. Two things\nI'd check:\n\n  1. Try \"git config --list --show-origin\" to make sure you do not\n     accidentally have incorrect config somewhere overriding what you\n     expect.\n\n  2. Try signing with \"GIT_TRACE=1\" set in the environment, which will\n     show the gpg command we run. E.g.:\n\n       $ GIT_TRACE=1 git -c user.signingkey=foobar tag -s -m foo bar\n       [...]trace: built-in: git tag -s -m foo bar\n       [...]trace: run_command: gpg --status-fd=2 -bsau foobar\n       [...]trace: start_command: /usr/bin/gpg --status-fd=2 -bsau foobar\n\n     If git is passing the correct \"-u\" option to gpg, then the bug (or\n     misconfiguration) may be in gpg.\n\n-Peff\n"},{"id":"509993","messageId":"cw6ggzhw4o5c5v5juh7sx2ubfaidnzugxx3ydgfvdlywqhndzf@6rfdfajvscif","threadId":"62638","inReplyTo":"20241216113543.GD2201417@coredump.intra.peff.net","subject":"Re: [Bug report] signingKey beying bypassed","fromName":"Carlos Maiolino","fromEmail":"cem@kernel.org","sentAt":"2025-01-06T14:55:32Z","receivedAt":"2025-01-06T14:55:36Z","isPatch":false,"sender":{"key":"cem@kernel.org","avatar":null},"body":"On Mon, Dec 16, 2024 at 06:35:43AM -0500, Jeff King wrote:\n> On Fri, Dec 13, 2024 at 09:23:29PM +0100, Carlos Maiolino wrote:\n> \n\nSorry the late reply Jeff... Holidays, family, the whole thing...\n\n> > the git-tag manpage states:\n> > \n> > \"\n> > CONFIGURATION\n> > \tBy default, git tag in sign-with-default mode (-s) will use your committer\n> > \tidentity (of the form Your Name <your@email.address>) to find a key. If you\n> > \twant to use a different default key, you can specify it in the repository\n> > \tconfiguration as follows:\n> > \n> >            [user]\n> >                signingKey = <gpg-key-id>\n> > \"\n> > \n> > \n> > I do have my $HOME/.gitconfig configured to always sign tags with a specific key\n> > per above documentation, and I just take it for granted.\n> > Today I had two smartcards connected, and when signing a tag, git-tag used the\n> > wrong key to sign the tag, instead of the specified in the .gitconfig.\n> > \n> > I believe this might be a bug or some expected behavior that doesn't match the\n> > manpage. Or perhaps I misinterpreted the manpage?\n> \n> No, I'd expect it to sign with the key that you configured. Two things\n> I'd check:\n> \n>   1. Try \"git config --list --show-origin\" to make sure you do not\n>      accidentally have incorrect config somewhere overriding what you\n>      expect.\n\nOk, this returns the 'correct' key:\n\n$ git config --list --show-origin|grep sign\nfile:$HOME/.gitconfig user.signingkey=0C...\n\nyet just creating a dummy tag on a dummy repo:\n\n$ git tag --verify foo\nobject 5d3928490fc1506afa0e0cfada15819e2eac922f\ntype commit\ntag foo\n.\n.\n.\ngpg:                using ECDSA key A6...\n\n\n> \n>   2. Try signing with \"GIT_TRACE=1\" set in the environment, which will\n>      show the gpg command we run. E.g.:\n> \n>        $ GIT_TRACE=1 git -c user.signingkey=foobar tag -s -m foo bar\n>        [...]trace: built-in: git tag -s -m foo bar\n>        [...]trace: run_command: gpg --status-fd=2 -bsau foobar\n>        [...]trace: start_command: /usr/bin/gpg --status-fd=2 -bsau foobar\n\nHmm, this actually works. Doing this, the tag is signed with the key I pass on\nthe CLI.\n\n> \n>      If git is passing the correct \"-u\" option to gpg, then the bug (or\n>      misconfiguration) may be in gpg.\n\nI particularly think git is the 'problem' here. After I tried GIT_TRACE, I decided\nto run it without specifying the key on the CLI as I'd normally do, and it did\nwork normally, and I think I what happens is git defaults for another key, if\nthe specified key is not available.\n\nAs I mentioned earlier, the key configured on my .gitconfig, is inside a\nsmartcard.\nI just tested creating a tag, without the smartcard connected, and git\nignored the signing key I passed, using another key.\n\nI am not sure how right I am, so please correct me if I'm not, but I would\nexpect git tag to fail, or at least give me a big warning if for any reason it\ncould not sign the tag with the specified key.\n\nCheers and happy new year\n\n\n> \n> -Peff\n"},{"id":"510043","messageId":"20250107030025.GA21698@coredump.intra.peff.net","threadId":"62638","inReplyTo":"cw6ggzhw4o5c5v5juh7sx2ubfaidnzugxx3ydgfvdlywqhndzf@6rfdfajvscif","subject":"Re: [Bug report] signingKey beying bypassed","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-07T03:00:25Z","receivedAt":"2025-01-07T03:00:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 06, 2025 at 03:55:32PM +0100, Carlos Maiolino wrote:\n\n> >      If git is passing the correct \"-u\" option to gpg, then the bug (or\n> >      misconfiguration) may be in gpg.\n> \n> I particularly think git is the 'problem' here. After I tried GIT_TRACE, I decided\n> to run it without specifying the key on the CLI as I'd normally do, and it did\n> work normally, and I think I what happens is git defaults for another key, if\n> the specified key is not available.\n\nGit doesn't know anything about available keys, though. We just call\n\"gpg\" with the signing key configured in your .gitconfig and it tells us\nwhether it worked or not.\n\nAre you saying that:\n\n  GIT_TRACE=1 git tag -sm foo foo\n\nshows git invoking gpg with the wrong key, but:\n\n  GIT_TRACE=1 git -c user.signingkey=$RIGHT_KEY -sm foo foo\n\nuses the right key? That implies something funny with the config\nreading. Or are there cases where GIT_TRACE shows us passing the right\nkey to gpg, but the signature is made with the wrong key? Then that is\nnot something git can control, and is a problem with gpg.\n\nCan you show us the exact commands you're running and their output?\n\n> As I mentioned earlier, the key configured on my .gitconfig, is inside a\n> smartcard.\n> I just tested creating a tag, without the smartcard connected, and git\n> ignored the signing key I passed, using another key.\n> \n> I am not sure how right I am, so please correct me if I'm not, but I would\n> expect git tag to fail, or at least give me a big warning if for any reason it\n> could not sign the tag with the specified key.\n\nI'd expect it to produce a warning, too, but we can only do so if gpg\ntells us it failed. From Git's perspective, we are just passing along\nthe key string from user.signingkey to gpg. We don't know what it means,\nand don't have any mechanism for using a different key.\n\n-Peff\n"},{"id":"510404","messageId":"47yfez6r4f4jitps3re23q5vp6vzjas5624f2mp3looocc2myg@vineab4jdxdl","threadId":"62638","inReplyTo":"20250107030025.GA21698@coredump.intra.peff.net","subject":"Re: [Bug report] signingKey beying bypassed","fromName":"Carlos Maiolino","fromEmail":"cem@kernel.org","sentAt":"2025-01-13T09:05:46Z","receivedAt":"2025-01-13T09:05:51Z","isPatch":false,"sender":{"key":"cem@kernel.org","avatar":null},"body":"Hi Jeff, sorry the delayed reply.\n\nOn Mon, Jan 06, 2025 at 10:00:25PM -0500, Jeff King wrote:\n> On Mon, Jan 06, 2025 at 03:55:32PM +0100, Carlos Maiolino wrote:\n> \n> > >      If git is passing the correct \"-u\" option to gpg, then the bug (or\n> > >      misconfiguration) may be in gpg.\n> > \n> > I particularly think git is the 'problem' here. After I tried GIT_TRACE, I decided\n> > to run it without specifying the key on the CLI as I'd normally do, and it did\n> > work normally, and I think I what happens is git defaults for another key, if\n> > the specified key is not available.\n> \n> Git doesn't know anything about available keys, though. We just call\n> \"gpg\" with the signing key configured in your .gitconfig and it tells us\n> whether it worked or not.\n> \n> Are you saying that:\n> \n>   GIT_TRACE=1 git tag -sm foo foo\n> \n> shows git invoking gpg with the wrong key, but:\n> \n>   GIT_TRACE=1 git -c user.signingkey=$RIGHT_KEY -sm foo foo\n> \n> uses the right key? That implies something funny with the config\n> reading. Or are there cases where GIT_TRACE shows us passing the right\n> key to gpg, but the signature is made with the wrong key? Then that is\n> not something git can control, and is a problem with gpg.\n> \n> Can you show us the exact commands you're running and their output?\n> \n> > As I mentioned earlier, the key configured on my .gitconfig, is inside a\n> > smartcard.\n> > I just tested creating a tag, without the smartcard connected, and git\n> > ignored the signing key I passed, using another key.\n> > \n> > I am not sure how right I am, so please correct me if I'm not, but I would\n> > expect git tag to fail, or at least give me a big warning if for any reason it\n> > could not sign the tag with the specified key.\n> \n> I'd expect it to produce a warning, too, but we can only do so if gpg\n> tells us it failed. From Git's perspective, we are just passing along\n> the key string from user.signingkey to gpg. We don't know what it means,\n> and don't have any mechanism for using a different key.\n\nFirst, I'd like to apologize because I'm not exactly sure if what I'm doing is\ncorrect, and exploring it a bit, I do agree with you this smells more a gnupg\nproblem after the information you provided.\n\nI was just playing around with it a bit. And I can't really understand gpg's\nbehavior here. As you asked, here is what I'm doing now:\n\n- I commented out the user.signingkey in my .config file, and I'm specifying it\n  on the CLI as you suggested.\n\nI have a subkey stored locally (besides the one in my smartcard). So, I tried to\nuse the locally stored key to create a new signed tag, in a random repo, with\nthis command:\n\n$GIT_TRACE=1 git -c user.signingkey=A6... tag -s foo -m \"bar\"\n\nFirst thing gnupg does is ask me to provide my smartcard passphrase, even tough\nmy smartcard is not even connected :)\n\nAfter I cancel the password request (I use pinentry, so it moves to the pwd\nprompt), I can see the trace:\n\n09:29:49.780058 git.c:479               trace: built-in: git tag -s foo -m bar\n09:29:49.781317 run-command.c:666       trace: run_command: gpg --status-fd=2 -bsau A6...\n09:29:49.781361 run-command.c:758       trace: start_command: /usr/bin/gpg --status-fd=2 -bsau A6...\nerror: gpg failed to sign the data:\n[GNUPG:] KEY_CONSIDERED 40... 0\n[GNUPG:] BEGIN_SIGNING H9\n[GNUPG:] PINENTRY_LAUNCHED 5587 curses 1.3.1-unknown /dev/pts/5 xterm-256color :0 20620/1000/5 1000/1000 0\ngpg: signing failed: Operation cancelled\n[GNUPG:] FAILURE sign 83886179\ngpg: signing failed: Operation cancelled\n\nSo, from my POV, git is passing the correct key to the gpg commandline, but for\nwhatever reason gpg is ignoring it.\n\nThe key it defaults to, is the one in my smartcard. I'm not sure why it is using\nit as the default, I don't have any default key configured in my gpg.\n\nWhen I cancel the pwd request for the key, gpg emits the KEY_CONSIDERED message,\nwith yet a different key, and fails the operation.\n\nWell, anyway, thanks for the help, but I do think now git is only a victim here\nof some weird behavior from gpg.\nI'll try to find out more information about this.\n\n\n> -Peff\n"}]}