'Git: gpg failed to sign the data' in visual studio code
Asked Answered
M

6

30

After a fresh Linux install I'm trying to set up my environment and I keep getting the Git: gpg failed to sign the data error upon committing changes locally. I'm using Visual Studio Code, proprietary, not opensource version.

.gitconfig:

[user]
    name = djweaver-dev
    email = [email protected]
    signingkey = 37A0xxxx...
[core]
    excludesfile = /home/dweaver/.gitignore_global
[commit]
    gpgSign = true

yikes. furthermore I can't find a way to copy the output log nor can I find where that log is so here is a pic:

output log

Steps I have taken so far:

  • generated new key (RSA 4096) in gnugp
  • added signing key to global .gitconfig
  • set "git.enableCommitSigning": true in Visual Studio Code settings
  • cloned my repo from github

Typically when I commits in the past I would get a dialog box requesting GPG authentication upon commit. I do not get this now, just the error dialog.

UPDATE: Okay now I'm really confused. I restarted vscode (not the first time I've done this in this process) and voilà, it works. Only thing I can think of is maybe I biffed the directory somehow? Either way, it works now.

UPDATE: Oddly, I'm back to this same issue almost a month later after a fresh arch install. I've tried everything that I've been able to find on this site, and nothing works.

I've tried adding export GPG_TTY=$(tty) to .bash_profile, and also .bashrc

Git log:

Looking for git in: git
Using git 2.26.2 from git
> git rev-parse --show-toplevel
> git rev-parse --git-dir
Open repository: /home/dw/dev/website
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
> git rev-parse --symbolic-full-name master@{u}
> git rev-list --left-right master...refs/remotes/origin/master
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
Failed to watch ref '/home/dw/dev/website/.git/refs/remotes/origin/master', is most likely packed.
Error: ENOENT: no such file or directory, watch '/home/dw/dev/website/.git/refs/remotes/origin/master'
    at FSWatcher.start (internal/fs/watchers.js:165:26)
    at Object.watch (fs.js:1270:11)
    at Object.t.watch (/usr/lib/code/extensions/git/dist/main.js:1:604919)
    at T.updateTransientWatchers (/usr/lib/code/extensions/git/dist/main.js:1:83965)
    at e.fire (/usr/lib/code/out/vs/workbench/services/extensions/node/extensionHostProcess.js:46:87)
    at e.updateModelState (/usr/lib/code/extensions/git/dist/main.js:1:103179)
> git config --get commit.template
> git check-ignore -v -z --stdin
> git check-ignore -v -z --stdin
> git commit --quiet --allow-empty-message --file - -S
error: gpg failed to sign the data
fatal: failed to write commit object
> git config --get-all user.name
> git config --get-all user.email

Same config as last time, user.name and user.email both match each key I've been trying it with... user.signingkey matches. Not sure where else to go with this one, as I've tried it across newly initialized local repos as well as repos that I've pulled from github both with official MS vscode (AUR) and OSS version, in the vscode terminal emulator as well as gnome terminal with same results so it has to be either a git thing or a gnugp thing.

What I have noticed is that after committing without signing, it will work immediately after: I get prompted for my key passphrase the first time, then it works on subsequent commits until a seemingly random number of minutes later, it just doesn't work anymore and the process has to be repeated.

There were a few macos users posting about having a stalled gpg-agent running in the background and it fixed it for them, however, I am seeing:

[dw@dwLinux website]$ gpg-agent
gpg-agent[2870]: gpg-agent running and available

Whats interesting also is that by doing echo "test" | gpg --clearsign I get the same results: it works for a short period of time, then I can't sign anymore.

UPDATE

Okay so day number 2 of trying to fix this. To rule out the gpg-agent theory as described here I followed the instructions on how to reload gpg-agent using the $ gpg-connect-agent reloadagent /bye command demonstrated on the Arch Linux Wiki

This had no effect

So being that I can reproduce this problem across vscode official, oss code, and vscodium, as well as bash, I thought maybe this was a permissions related issue, as so many problems with linux typically are. I added my user to all kinds of groups, including root, and this also had no effect so I think I can safely rule out the following:

  • VS Code
  • GnuGP
  • gpg-agent
  • Linux permissions

So my next focus was the config files themselves, but as has been stated before the credentials match the key in .gitconfig and my .bash_profile has been correctly configured with export GPG_TTY=$(tty).

An interesting note on this from the official GnuPG docs shows a syntax discrepency between their way, and the way you are instructed to append this to .bash_profile on the GitHub docs here

From GnuPG: "The far most common reason for this is that the environment variable GPG_TTY has not been set correctly. Make sure that it has been set to a real tty device and not just to ‘/dev/tty’; i.e. ‘GPG_TTY=tty’ is plainly wrong; what you want is ‘GPG_TTY=tty’ — note the back ticks. Also make sure that this environment variable gets exported, that is you should follow up the setting with an ‘export GPG_TTY’"

As I understood $(whatever) in bash was to execute a command, but for safe measure I've appended .bash_profile using both ways and neither solved the issue.

One last thing

In this post the user talks about gpg-agent authentication not being available when daemonized and gpg access is being initiated by another application (such as an IDE like VSCode), which explains how I could temporarily sign commits after committing a random file or doing echo "test" | gpg --clearsign and being authenticated... but alas like most other 'solutions' to this topic, they reveal that all they had to do in the end was add export GPG_TTY=$(tty) to their .bash_profile, which I have already tried.

Where to go from here?

I still can't explain why it worked on my previous install, and frankly, not a whole lot has changed afaik. I typically do fresh installs often and keep a pretty minimal arch linux build with lts kernel each time w/base-devel and nodejs/python/git/vscode/firefox/discord is pretty much my entire workflow. I'm all out of ideas.

Maria answered 6/4, 2020 at 19:58 Comment(5)
This worked for me: If you are using VSCode in WSL mode like me, try doing the signed commit from the (WSL) terminal inside VSCode, it'll ask for your password once and commit. I'll work with VSCode integration onwards. Let me know if this doesn't work, or if you're not using WSL, since I've figured that as well nowJungle
@DaniloRamirez this seems to only be a temporary workaround. It works for a little bit (few hours), and then proceeds with the same issue. Is yours working permanently with this solution?Solly
@LewlSauce, I can't recall, sorry. I dumped WSL on vscode around a month after that comment was posted. Moved to Ubuntu entirely. it probably was temporary, but it's been a while, so I would be hoping vscode team have solved it for you alreadyJungle
Just a note for the impatient - this error message can also manifest if your key has expired.Dasha
I had a failure when updating macOS to 12.3 with GPG Keychain. You can see the solution on the GPG Keychain website.Zymosis
D
36

first make sure to add

export GPG_TTY=$(tty)

in your .bashrc

Apparently VSCode doesn't ask for the passphrase and that's why it gives an error. I don't know the reason. My personal solution do a console commit first or run the following line

echo "test" | gpg --clearsign

Edit

In order to avoid typing the passphrase on every commit, you can make GPG remember it for 8 hours or until the next reboot:

mkdir -p ~/.gnupg
echo "default-cache-ttl 28800" >> ~/.gnupg/gpg-agent.conf

GitHub Guide

Droop answered 22/1, 2022 at 7:17 Comment(4)
This is an excellent way to test if your gpg key is usable without using git.Dasha
This answer needs a very important missing bit. That is, In the VSCode, Open an integrated terminal window and then run the command in this answer. You will be asked to provide the passphrase and then in that session all signed commits will work. If you close and open VSCode again, you need to do this again, Open integrated terminal window...Unconcerned
Yeah, this was it for me. VSCode (on mac) is not asking for the passphrase. This is a great workaround.Disc
this is a workaround. Issue is that pinentry requires a tty and vscode is not connected to one. Need to set a graphical pinentry program for your gpg, for example pinentry-gtk2 which does not need a tty. Note that it still won't work over ssh but it'll work on WSL. Ideally vscode devs need to solve this by handling the pinentry sideWorkday
D
9

Maybe git cannot find gpg? That was my problem with working with VSCode and using Remote-Containers to create development containers. Try running this in the Terminal within VSCode (in the container)

git config --global --unset gpg.program
git config --global --add gpg.program /usr/bin/gpg

or wherever your gpg is located. You can find out by typing

which gpg

If that works then you can put it in your Dockerfile for your development container.

Dowden answered 2/11, 2020 at 7:40 Comment(0)
O
7

I had the same issue a few days ago while using VS Code with WSL. The problem is that VS Code doesn't load the .profile file (and all the environment variables in it) correctly (try to run this command but it doesn't get the correct result: echo $GPG_TTY). Fortunately, setting the "-l" option for shell args in VS Code preferences worked for me. This ensures that the .profile (or .zprofile) file is successfully loaded. I added these lines to settings.json:

"terminal.integrated.shellArgs.linux": [
    "-l"
]

Make sure to add export GPG_TTY=$(tty) in your .profile file and restart your terminal and VS Code.


Update: Since VSCode is deprecating the shellArgs oprion, use the following snippet as an alternative.

"terminal.integrated.profiles.linux": {
    "bash": {
        "path": "bash",
        "args": ["-l"],
        "icon": "terminal-bash"
    },
    "zsh": {
        "path": "zsh",
        "args": ["-l"],
    },
    "fish": {
        "path": "fish",
        "args": ["-l"],
    },
    "tmux": {
        "path": "tmux",
        "args": ["-l"],
        "icon": "terminal-tmux"
    },
    "pwsh": {
        "path": "pwsh",
        "args": ["-l"],
        "icon": "terminal-powershell"
    }
},
"terminal.integrated.defaultProfile.linux": "bash"

-l option is added to all terminal profiles above, delete unused profiles and set your default profile at your wish.

Obsidian answered 9/8, 2020 at 22:13 Comment(3)
I added export in the .zprofile, updated settings, restarted and the problems persistsHaycock
Note that This is deprecated, use #terminal.integrated.defaultProfile.linux# insteadMailbox
@Mailbox what value should be set to terminal.integrated.defaultProfile.linux , is it same "-l" and is it going to be one value in an array or just one value "-l"?Unconcerned
S
4

I have same issue, and I have resolved it.

Background

  • macOS
  • GPG Suite to generate GPG key
  • pinentry-mac

How I solve this problem

I saw this answer, and followed it.

  1. Get keys
gpg2 --list-keys

Result

/Users/xxuser/.gnupg/pubring.kbx
---------------------------------
pub   dsa2048 2010-08-19 [SC] [expires: 2024-05-11]
      85E38F69046BSDFB07B76D78F0500D026C4
uid           [ unknown] GPGTools Team <[email protected]>
uid           [ unknown] [jpeg image of size 6329]
sub   rsa4096 2014-04-08 [S] [expires: 2024-05-11]
sub   rsa4096 2020-05-11 [E] [expires: 2024-05-11]

pub   rsa4096 2020-05-04 [SC] [expires: 2024-05-03]
      B97E9964ACAD1928300D37CC8A9E3745558E41AF
uid           [ unknown] GPGTools Support <[email protected]>
sub   rsa4096 2020-05-04 [E] [expires: 2024-05-03]

pub   rsa4096 2021-07-29 [SC] [expires: 2025-07-29]
      926E268C01892E8A2FCCD2A101CEB6267272A9A5
uid           [ultimate] xxuser <[email protected]>
sub   rsa4096 2021-07-29 [E] [expires: 2025-07-29]
  1. Since [email protected] is the email that I create secret for, 926E268C01892E8A2FCCD2A101CEB6267272A9A5 is the key code I need.
  2. Let git user this key.
git config --global user.signingkey 926E268C01892E8A2FCCD2A101CEB6267272A9A5
  1. Now it should work.
git commit -S -m "This is a signed commit"

note If you need it to work with Github, you need to add your public GPG key to Github, following this Guide.

Sharell answered 30/7, 2021 at 3:12 Comment(0)
O
1

Make sure echo "test" | gpg --clearsign runs successfully first before trying the below.

Very helpful to check what git commit is doing under the hood. Run the following commit with GIT_TRACE=1 as follow

GIT_TRACE=1 git commit -S -m "MESSAGE"

This will show what user name, email and key does git uses when committing.

In my case, I found that git was picking up the wrong user's and key details for signing the commit. I mainly intended to use the local config of the repo rather than the global and adding the following to the local git config (located at "REPO_PATH/.git/config") got signing the commit to work both in Terminal and VSCode

[user]
    name = USER NAME
    email = USER EMAIL
    signingKey = SIGNING KEY

It can also be set with the following:

git config --local user.name "USER NAME"
git config --local user.email "USER EMAIL"
git config --local user.signingkey "USIGNING KEY"
Occupation answered 26/8, 2022 at 8:57 Comment(0)
A
1

I'm not sure if this is too late, but... I did find an immediate solution.

To see what user.name and user.email you have, run:

git config -l

You may notice two entries for user.name. You may have made the same mistake as me! I put my actual name in there instead of GitHub username, and there ended up being two entries of user.name! I just changed the global user.name back to my github username, like so...

git config --global user.name "ghusername"

Next, git commit, and it should work:

git commit -m "<YOUR MESSAGE>"

Let me know if this works for you, I want to know if it's the same problem.

Albertson answered 22/9, 2022 at 23:36 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.