I face similar issue. I uninstalled Git 2.8 (git-scm) on Windows. And installed 2.10. Now I get 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.
– IlluminatorSep 16 '16 at 15:30

An irony, I'd changed my machine to set up things afresh and ended up looking for my own question and none of the suggested solution looks clean enough to me to just get started simply.
– nullpointerMar 15 at 4:11

@StuartCardall What is the point of the chown command? Typically it will have already been assigned to you by a system process, when you logged in or created the pseudo-tty. If it's owned by someone else and you're not root, it will fail. If the group is something else, it probably doesn't matter, and users will typically not be in group tty.
– poolieNov 12 '17 at 19:17

@poolie - it matters if you su to root on a remote server
– Stuart CardallNov 12 '17 at 20:31

3

I added the variable to ~/.zshrc and I can make commits again, now that it connects correctly to the terminal. Thanks for all your help!
– Alex GurrolaNov 16 '17 at 23:27

Thanks! This led me to my problem. Strangely enough my local .git/config had a name specified in one project that did not match my signing email. That was enough to reject it.
– krossJan 24 at 20:11

1

Well, executing 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?
– nullpointerMar 15 at 4:03

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.

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.

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.

This does not at all solve the problem presented here.
– rugkSep 8 at 10:16

@rugk it can be used to disable the gpgsign which is a workaround to push a commit if you want gpgsign disabled for a project.
– nmargaritisOct 10 at 13:38

Indeed, it is a workaround. However your wording in the answer implies this is the last solution that worked/works, i.e. everything else failed. And there are clearly ways to make it work without having to disable it. (see answers above) Also, you should mention what the command does, you execute here, so one is aware that it just disables gpg signing.
– rugkOct 11 at 20:33

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).