I followed few articles over the pretty attributes on Git 2.10 release note. Going through which upgraded the git to 2.10.0 and made changes to global .gitconfig
resulting as follows -
[filter "lfs"]
clean = git-lfs clean %f
smudge = git-lfs smudge %f
required = true
[user]
name = xyz
email = abc.def@gmail.com
signingkey = AAAAAAA
[core]
excludesfile = /Users/xyz/.gitignore_global
editor = 'subl' --wait
[difftool "sourcetree"]
cmd = opendiff \"$LOCAL\" \"$REMOTE\"
path =
[mergetool "sourcetree"]
cmd = /Applications/SourceTree.app/Contents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor \"$BASE\" -merge \"$MERGED\"
trustExitCode = true
[alias]
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
[color "diff"]
old = red strike
new = green italic
But now that I try to sign my commits using
git commit -a -S -m "message"
I get to see the following error -
You need a passphrase to unlock the secret key for user: "XYZ (Digitally Signed) " 2048-bit RSA key, ID AAAAAAAA, created 2016-07-01 error: gpg failed to sign the data fatal: failed to write commit object
Note - I can still commit changes using git commit -a -m "message"
Is there a way to overcome the same? Or any change required in gpg
configs to get along with the upgradation of git?
Update 1
Also seeking further usefulness, following Is there a way to "autosign" commits in Git with a GPG key?. I've already configured the key using
git config --global user.signingkey ED5CDE14(with my key)
git config --global commit.gpgsign true
and quite obviously getting the same error anyway.
gpg failed to sign the data
every time I use -S
. In 2.8, I can sign a commit without problem. I don't know what happen.
user.signingkey
fixed my issue, strangely enough.
gpgconf --kill gpg-agent
as discussed here
git config --get-all user.name
and git config --get-all user.email
are same as key used for signing, which can be checked via gpg -K --keyid-format SHORT
I ran into this issue with OSX.
Original answer:
It seems like a gpg update (of brew) changed to location of gpg
to gpg1
, you can change the binary where git looks up the gpg:
git config --global gpg.program gpg1
If you don't have gpg1: brew install gpg1
.
Updated answer:
It looks like gpg1 is being deprecated/"gently nudged out of usage", so you probably should actually update to gpg2, unfortunately this involves quite a few more steps/a bit of time:
brew upgrade gnupg # This has a make step which takes a while
brew link --overwrite gnupg
brew install pinentry-mac
on old homebrew:
echo "pinentry-program /usr/local/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf
killall gpg-agent
On more recent systems like M1 macs:
echo "pinentry-program /opt/homebrew/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf
killall gpg-agent
The first part installs gpg2, and latter is a hack required to use it. For troubleshooting, see this answer (though that is about linux not brew), it suggests a good test:
echo "test" | gpg --clearsign # on linux it's gpg2 but brew stays as gpg
If this test is successful (no error/output includes PGP signature), you have successfully updated to the latest gpg version.
You should now be able to use git signing again! It's worth noting you'll need to have:
git config --global gpg.program gpg # perhaps you had this already? On linux maybe gpg2
git config --global commit.gpgsign true # if you want to sign every commit
Note: After you've run a signed commit, you can verify it signed with:
git log --show-signature -1
which will include gpg info for the last commit.
If gnupg2 and gpg-agent 2.x are used, be sure to set the environment variable GPG_TTY
.
export GPG_TTY=$(tty)
See GPG’s documentation about common problems.
set -x GPG_TTY (tty)
on your profile.
~/.zshrc
and I can make commits again, now that it connects correctly to the terminal. Thanks for all your help!
zsh
users with Powerlevel10k with Instant Prompt enabled beware, you might end up with a not a tty
value: unix.stackexchange.com/a/608921/5095. A quick workaround is to just use a much faster and safer (in the context of Zsh): export GPG_TTY=$TTY
.
If everything fails, use GIT_TRACE=1
to try and see what git is actually doing:
$ GIT_TRACE=1 git commit -m "Add page that always requires a logged-in user"
20:52:58.902766 git.c:328 trace: built-in: git 'commit' '-vvv' '-m' 'Add page that always requires a logged-in user'
20:52:58.918467 run-command.c:626 trace: run_command: 'gpg' '--status-fd=2' '-bsau' '23810377252EF4C2'
error: gpg failed to sign the data
fatal: failed to write commit object
Now run the failing command manually:
$ gpg -bsau 23810377252EF4C2
gpg: skipped "23810377252EF4C2": Unusable secret key
gpg: signing failed: Unusable secret key
Turns out, my key was expired, git
was not to blame.
.git/config
had a name
specified in one project that did not match my signing email. That was enough to reject it.
gpg -bsau <key>
on my machine doesn't execute anything. Is this suppose to take too long to execute? Or does that mean the key is fine to be used? @VonC any insights?
Follow the below url to setup signed commit https://help.github.com/en/articles/telling-git-about-your-signing-key
if still getting gpg failed to sign the data fatal: failed to write commit object
this is not issue with git ,this is with GPG follow below steps
gpg --version echo "test" | gpg --clearsign
if it is showing:
gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device
then use export GPG_TTY=$(tty) then again try echo "test" | gpg --clearsign in which PGP signature is got. git config -l | grep gpg
gpg.program=gpg
commit.gpgsign=true
apply git commit -S -m "commitMsz"
export GPG_TTY=$(tty)
was the trick. Added that to my .zshrc
file
export GPG_TTY=$(tty)
. The difference here is that @jayesh also offered a test and nothing about gpg2, fish, or brew which are not related (?) to anything in Ubuntu. This is also a more recent answer, which for my purposes means at this moment this answer might be better than those that are a couple years old. So good job on this short, effective, and up-to-date posting.
export GPG_TTY=$(tty)
. This worked beautifully.
export GPG_TTY=$(tty)
! Confirmed on Kali ARM 5.4.83-Re4son-v7l+
and gpg (GnuPG) 2.2.27
.
I've DONE it through this short and easy recipe:
Auto-sign commits on macOS (Globally and with different IDEs):
Get your signingkey
in this way.
brew install gnupg gnupg2 pinentry-mac
git config --global user.signingkey <YOUR_SIGNING_KEY>
git config --global commit.gpgsign true
git config --global gpg.program gpg
Put the following in gpg.conf
file (edit file with nano ~/.gnupg/gpg.conf
command):
no-tty
Put the following in gpg-agent.conf
file (edit file with nano ~/.gnupg/gpg-agent.conf
command):
pinentry-program /usr/local/bin/pinentry-mac
Update:
As suggested in the comments, you might need to execute killall gpg-agent
command after editing the configurations file, gpg.conf
, according to the comments. needless to say that this command will terminate the GPG (Gnu Privacy Guard) agent.
killall gpg-agent
after setting the config files, then it worked!
pinentry-mac
? I don’t say we can’t, but the GPGTools org is backup by a very small team and the repo has only 5 contributors vs using brew install gnupg
which leverages the work of gnupg.org.
user.signingkey
set, which I didn't notice in my sourcetree configuration, nor my global settings (because I didn't think to look at local config) Ensure both local (git config --local --get user.signingkey
) and global (git config --global --get user.signingkey
) are the same, or even better, unset the local one if it is invalid (git config --local --unset user.signingkey
)
pinentry-mac
will be /opt/homebrew/bin/pinentry-mac
May help killing process gpg-agent
that might stuck with old data. So new gpg-agent
started would ask for password.
gpg-agent --daemon
to start it
killall gpg-agent
gpgconf --kill gpg-agent
My two cents here:
When you create and add a key to gpg-agent you define something called passphrase
. Now that passphrase
at some point expires, and gpg
needs you to enter it again to unlock your key so that you can start signing again.
When you use any other program that interfaces with gpg
, gpg
's prompt to you to enter your passphrase does not appear (basically gpg-agent
when daemonized cannot possibly show you the input dialog in stdin
).
One of the solutions is gpg --sign a_file.txt
then enter the passphrase that you have entered when you created your key and then everything should be fine (gpg-agent
should automatically sign)
See this answer on how to set longer timeouts for your passphrase so that you do not have to do this all the time.
Or you can completely remove the passphrase with ssh-keygen -p
Edit: Do a man gpg-agent
to read some stuff on how to have the above happen automatically and add the lines:
GPG_TTY=$(tty)
export GPG_TTY
on your .bashrc if you are using bash(this is the correct answer but I am keeping my train of thought above as well) then source your .bashrc
file or relogin.
To anybody who is facing this issue on MacOS machines, try this:
brew uninstall gpg brew install gpg2 brew install pinentry-mac (if needed) gpg --full-generate-key Create a key by using an algorithm. Get generated key by executing: gpg --list-keys Set the key here git config --global user.signingkey
If the issue still exists:
test -r ~/.bash_profile && echo 'export GPG_TTY=$(tty)' >> ~/.bash_profile
echo 'export GPG_TTY=$(tty)' >> ~/.profile
If the issue still exists:
Install https://gpgtools.org and sign the key that you used by pressing Sign from the menu bar: Key->Sign
If the issue still exists:
Go to: your global .gitconfig
file which in my case is at: /Users/gent/.gitconfig
And modify the .gitconfig file (please make sure Email and Name are the same with the one that you have created while generating the Key):
[user]
email = gent@youremail.com
name = Gent
signingkey =
I've seen similar answers, but nothing exactly like what worked for me. On Linux, I had to kill and restart my gpg-agent
with:
$ pkill gpg-agent
$ gpg-agent --daemon
$ git commit ...
This did the trick for me. It looks like you do need to have user.signingkey
set to your private key as well from what some other comments are saying.
$ git config --global user.signingkey [your_key_hash]
On OS X, using gnupg2
via brew I just had to kill the gpg agent, happens sometimes:
pkill -9 gpg-agent
And set the env
variable if needed:
export GPG_TTY=$(tty)
See Common GPG problems also and this answer here too.
alias fix-gpg='pkill -9 gpg-agent && export GPG_TTY=$(tty)'
.
I get that error every time I logout then login again on my macOS. The solution is just a simple single command:
killall gpg-agent
I think it's just an error from gpg agent, kill it then working again.
The git trace was very revealing for my situation...
GIT_TRACE=1 git commit -m "a commit message"
13:45:39.940081 git.c:344 trace: built-in: git commit -m 'a commit message'
13:45:39.977999 run-command.c:640 trace: run_command: gpg --status-fd=2 -bsau 'full name <your-email@domain.com>'
error: gpg failed to sign the data
fatal: failed to write commit object
I needed to generate an initial key per the format that git
was checking against. It's best to copy the value passed to -bsau
above in the logs as is and use below.
So it becomes,
gpg --quick-generate-key "full name <your-email@domain.com>"
Then it worked.
Update Oct. 2016: issue 871 did mention "Signing stopped working in Git 2.9.3"
Git for Windows 2.10.1 released two days ago (Oct. 4th, 2016) has fixed Interactive GPG signing of commits and tag.
the recent gpg-sign change in git (which introduces no problem on Linux) exposes a problem in the way in which, on Windows, non-MSYS2-git interacts with MSYS2-gpg.
Original answer:
Reading "7.4 Git Tools - Signing Your Work", I assume you have your "user.signingkey
" configuration set.
The last big refactoring (before Git 2.10) around gpg was in commit 2f47eae2a, here that error message was moved to gpg-interface.c
A log on that file reveals the recent change in commit af2b21e (Git 2.10)
gpg2 already uses the long format by default, but most distributions seem to still have "gpg" be the older 1.x version due to compatibility reasons. And older versions of gpg only show the 32-bit short ID, which is quite insecure. This doesn't actually matter for the verification itself: if the verification passes, the pgp signature is good. But if you don't actually have the key yet, and want to fetch it, or you want to check exactly which key was used for verification and want to check it, we should specify the key with more precision.
So check how you specified your user.signingkey
configuration, and the version of gpg you are using (gpg1 or gpg2), to see if those have any effect on the error message.
There is also commit 0581b54 which changes the condition for the gpg failed to sign the data
error message (in complement to commit 0d2b664):
We don't read from stderr at all currently. However, we will want to in a future patch, so this also prepares us there (and in that case gpg does write before reading all of the input, though again, it is unlikely that a key uid will fill up a pipe buffer).
Commit 4322353 shows gpg now uses a temporary file, so there could be right issues around that.
Let's convert to using a tempfile object, which handles the hard cases for us, and add the missing cleanup call.
user.signingkey
config set. Also using gpg (GnuPG) 2.0.3
.
gpg --list-keys
won't give the same output as "C:\Program Files\Git\usr\bin\gpg.exe" --list-keys
thus, git won't find your key when trying to sign a commit because it's using the "wrong" gpg
Using cygwin, I recently switched to gpg2
. Then I had the same problem for signing with git after setting git config gpg.program gpg2
.
Try echo "test" | gpg2 --clearsign
to see whether gpg2 is working. I found it the easiest solution to just set git config gpg.program gpg
, because that works. But you will also get a better error this way - e.g. that you need to install pinentry.
gpg: signing failed: Inappropriate ioctl for device
which can be solved by export GPG_TTY=$(tty)
. Source: github.com/keybase/keybase-issues/issues/2798
I got this error on Ubuntu 18.04 and it turned out that my key was expired.
To see this, I ran this and it confirmed that my keys were expired:
gpg --list-keys
To correct this, I ran (using the ID displayed in the previous command):
gpg --edit-key <ID>
From there, I extended the expiration of key 0
and key 1
following these instructions which boiled down to typing key 0
then expire
and following the prompts. Then repeating for key 1
.
Afterward, to test this, I ran:
echo test | gpg --clearsign
And before the fix, it failed with the error:
gpg: no default secret key: No secret key gpg: [stdin]: clear-sign failed: No secret key
But after the fix, the same command successfully signed the message so I knew things were working again!
If you use homebrew on a M1 chip without Rosetta, you need to specify a different location of the pinentry-program binary because it's installed at a different place.
Andy Hayden's updated answer should be modified as follow:
brew upgrade gnupg # This has a make step which takes a while
arch -arm64 brew link --overwrite gnupg
arch -arm64 brew install pinentry-mac
echo "pinentry-program /opt/homebrew/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf
killall gpg-agent
echo "test" | gpg --clearsign
output was gpg: signing failed: Inappropriate ioctl for device gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device
. This worked for me.
arch -arm64
every time if you are on m1, follow this to install brew for m1
I ran into the same problem. I'm happy to report that the issue lies not with git 2.10.0
but with gnupg 1.4.21
.
Temporarily downgrading gnupg to 1.4.20 fixed the issue for me.
If you're using homebrew and you upgraded your packages like I did, you can probably just run brew switch gnupg 1.4.20
to revert back.
I must have accidentally updated gpg somehow because I got this after trying to test if gpg works:
gpg: WARNING: server 'gpg-agent' is older than us (2.1.21 < 2.2.10)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
Running gpgconf --kill all
fixed it for me.
Make sure you have your email set properly.
git config --global user.email "user@example.com"
This started happening all of a sudden for me on Ubuntu, not sure if some recent update did it, but none of the existing issues were applicable for me (I had GPG_TTY
set, tried killing the agent etc.). The standalone gpg
command was failing with this error:
$ echo "test" | gpg --clearsign
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
test
gpg: signing failed: Operation cancelled
gpg: [stdin]: clear-sign failed: Operation cancelled
I tried running gpg
with --debug-all
option and noticed the below output:
gpg: DBG: chan_3 <- INQUIRE PINENTRY_LAUNCHED 27472 gnome3 1.1.0 /dev/pts/6 screen-256color -
gpg: DBG: chan_3 -> END
gpg: DBG: chan_3 <- ERR 83886179 Operation cancelled <Pinentry>
gpg: signing failed: Operation cancelled
The above indicates that there is some issue with the pinentry
program. Gpg normally runs pinentry-curses
for me, so I changed it to pinentry-tty
(I had to aptitude install
it first) and the error went away (though I no longer get the fullscreen password entry, but I don't like that anyway). To make this change, I had to add the line pinentry-program /usr/bin/pinentry-tty
to ~/.gnupg/gpg-agent.conf
and kill the agent with gpgconf --kill gpg-agent
(it gets restarted the next time).
Apart from not having setup your gpg key with git correctly, another possible problem: Trying to commit from inside an ssh session with X forwarding. In this case it could try to invoke a GUI which will fail if the env var DISPLAY
isn’t set.
You can force gpg-agent to use a tty-only tool by editing your ~/.gnupg/gpg-agent.conf
:
pinentry-program /usr/bin/pinentry-tty
Then reload the conf:
gpg-connect-agent reloadagent /bye
(of course install pinentry-tty first)
gpg-connect-agent reloadagent /bye
was the key for me. Thanks!
I stumbled upon this error not because of any configuration issue, but because my key was expired. The easiest way to extend its validity on OSX is to open the GPG Keychain app (if you have it installed) and it will automatically prompt you to extend it. Two clicks, and you're done.
If the email assoicated to your GPG key's uid is different to the email you are using in git, you'll need to add another user id to your key OR use a key which email matches exactly.
You can add another UID by using:
$ gpg --edit-key
See for mo https://superuser.com/questions/293184/one-gnupg-pgp-key-pair-two-emails
After searching a lot, I found that gpg key was the issue in my case.
To check if gpg key is an issue for you, first check output of the following:
GIT_TRACE=1 git commit -m 'message'
If something is wrong then you will see something like:
10:37:22.346480 run-command.c:637 trace: run_command: gpg --status-fd=2 -bsau <your GPG key>
It was showing my name and email in GPG key here but this should have the key. You can try running gpg --status-fd=2 -bsau <your GPG key>
To update your correct key, do the following: check key using: gpg --list-secret-keys --keyid-format=long
It should have the following output:
/Users/hubot/.gnupg/secring.gpg
------------------------------------
sec 4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10]
uid Hubot
ssb 4096R/42B317FD4BA89E7A 2016-03-10
And then update the key using:
git config --global user.signingkey 3AA5C34371567BD2
Now check the commit again and it should success if key was the issue. You need to set the passphrase to update the key which you can do using GitHub docs.
More details are at: https://gist.github.com/paolocarrasco/18ca8fe6e63490ae1be23e84a7039374
I had a similar issue with the latest Git sources (2.12.2) built along with the latest sources of all its dependencies (Zlib, Bzip, cURL, PCRE, ReadLine, IDN2, iConv, Unistring, etc).
It turns out libreadline
was giving GnuPG problems:
$ gpg --version
gpg: symbol lookup error: /usr/local/lib/libreadline.so.7: undefined symbol: UP
And of course, trying to get useful information from Git with -vvv
failed, so the failure was a mystery.
To resolve the PGP failure due to ReadLine, follow the instructions at Can't update or use package manager -- gpg error:
In terminal: ls /usr/local/lib there was a bunch of readline libs in there (libreadline.so.BLAH-BLAH) so i: su mkdir temp mv /usr/local/lib/libreadline* temp ldconfig
If this just happened randomly and has been working perfectly in the past, as is my case, try logging out (cmd+shift+q
) and logging back in. Worked for me
The answers above are great but they did not work for me. What solved my issue was exporting both the public and secret keys.
list the keys from machine where we are exporting from
$ gpg --list-keys
/home/user/.gnupg/pubring.gpg
--------------------------------
pub 1024D/ABCDFE01 2008-04-13
uid firstname lastname (description) <email@example.com>
sub 2048g/DEFABC01 2008-04-13
export the keys
$ gpg --output mygpgkey_pub.gpg --armor --export ABCDFE01
$ gpg --output mygpgkey_sec.gpg --armor --export-secret-key ABCDFE01
go to machine we are importing to and import
$ gpg --import ~/mygpgkey_pub.gpg
$ gpg --allow-secret-key-import --import ~/mygpgkey_sec.gpg
bingo bongo, you're done!
reference: https://www.debuntu.org/how-to-importexport-gpg-key-pair/
ps. My keys were originally made on bootcamp windows 7 and I exported them onto my mac air (same physical machine, different virtually)
Very much like @birchlabs, after a lot of digging/searching I found that it wasn't GPG, but rather GPG Suite. I did cask reinstall gpg-suite
and it solved it for me.
I am on Ubuntu 18.04 and got the same error, was worried for weeks too. Finally realized that gpg2 is not pointing towards anything. So simply run
git config --global gpg.program gpg
And tada, it works like charm.
https://i.stack.imgur.com/fUTps.png
Your commits will now have verified tag with them.
Success story sharing
killall gpg-agent && gpg-agent --daemon --use-standard-socket --pinentry-program /usr/local/bin/pinentry
finally fixed it for megit config --global user.signingkey <short Key ID>
😖.echo "pinentry-program /opt/homebrew/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf