Error gpg failed to sign the data fatal failed to write commit object

paolocarrasco / README.md

You have installed GPG, then tried to commit and suddenly you see this error message after it:

For understanding what’s going on, first check what git is doing, so add GIT_TRACE=1 at the beginning of the command you used before ( git commit or git rebase ):

With that you can see what GPG is doing: Probably you will see something like this

(Check if your GPG key is correct)

Execute that gpg command again in the command line:

👆🏻 With this now you could see what happened in detail!

We can have many problems, but I list what I found:

1. It could be that the GPG key was expired: https://stackoverflow.com/a/47561300/532912
2. Another thing could be that the secret key was not set properly (In my case the message said gpg: signing failed: No secret key as it can be see in the image below). It means that is not finding the key that was set. You would need to set up the GPG key in Git (again):
   • List the secret keys available in GPG.

• Copy your key
• Set your key for your user in git

Thanks, debug info: [GNUPG:] KEYEXPIRED , trace flag is awesome!

After upgrading my OSX to Monterey it stoped to work without reason. The GIT_TRACE didn’t help to much because everything was correctly set. In the end I reinstalled the GPG Sutie via brew with the command brew reinstall —cask gpg-suite and it fixed the issue.

omg I just need to run export GPG_TTY=$(tty)

dude that was a little bit overrated declaretion, its just my opinion

This option is for setting the path in .gitconfig to gpg.exe in the windows os environment.

@exostin solution worked for me. Thanks

There’s another situation:

While GitHub documentation operates with AAAAAAAAAAAAA in sections when you need to create and register the key in GPG, git requires BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB, i.e. git config —global user.signingkey BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB , instead of git config —global user.signingkey AAAAAAAAAAAAA

Hopefully, it helps someone.

I got a case when signing suddenly stopped working. After a long fight nothing has helped except gpgconf —kill gpg-agent

If you are on Windows and have used GPG4Win to manage your keys then you need to set the GPG program path.

If you look at where your gpg instance comes from mine looked like

My gpg path was C:Program Files (x86)Gpg4win..GnuPGbingpg.exe . That’s quite a weird path .

But technically it is the same as «C:Program Files (x86)GnuPGbingpg.exe»

So now set GIT to use this path:

Essentially it seemed that the gpg program that was being used was different to the one being run when I used gpg on the command line.

if all of the above did not work for you

I got into a slightly different problem, everything up there ALREADY CHECKED, somehow my gpg signing stopped working — and i don’t want to restart my server. After digging around i found this log

Some output of systemctl —user status gpg-agent

Note that until this point, it’s not about git anymore, it’s about gpg and distro-specific issues.

FIXED (the root cause is pinentry screwed things up)
Create gpg-agent.conf if you don’t have one under your home dir and add the line below ( pinentry-program /usr/bin/pinentry-curses )

Then you have to restart gpg-agent by issuing systemctl —user restart gpg-agent and you may want to log-in/out. Make sure to export GPG_TTY=$(tty) and test again. Good luck

Check my write-up here for the summary nguyenvulong/QA#25

Источник

Sign commits with GPG

You can sign the commits you make in a GitLab repository with a GPG (GNU Privacy Guard) key. When you add a cryptographic signature to your commit, you provide extra assurance that a commit originated from you, rather than an impersonator. If GitLab can verify a commit author’s identity with a public GPG key, the commit is marked Verified in the GitLab UI. You can then configure push rules for your project to reject individual commits not signed with GPG, or reject all commits from unverified users.

For GitLab to consider a commit verified:

• The committer must have a GPG public/private key pair.
• The committer’s public key must be uploaded to their GitLab account.
• One of the email addresses in the GPG public key must match a verified email address used by the committer in GitLab. To keep this address private, use the automatically generated private commit email address GitLab provides in your profile.
• The committer’s email address must match the verified email address from the GPG key.

GitLab uses its own keyring to verify the GPG signature. It does not access any public key server.

GPG verified tags are not supported.

For more details about GPG, refer to the related topics list.

View a user’s public GPG key

To view a user’s public GPG key, you can either:

• Go to https://gitlab.example.com/ .gpg . GitLab displays the GPG key, if the user has configured one, or a blank page for users without a configured GPG key.
• Go to the user’s profile (such as https://gitlab.example.com/ ). In the top right of the user’s profile, select View public GPG keys ( ).

Configure commit signing

Create a GPG key

If you don’t already have a GPG key, create one:

Install GPG for your operating system. If your operating system has gpg2 installed, replace gpg with gpg2 in the commands on this page.

To generate your key pair, run the command appropriate for your version of gpg :

To list your private GPG key, run this command, replacing with the email address you used when you generated the key:

In the output, identify the sec line, and copy the GPG key ID. It begins after the / character. In this example, the key ID is 30F2B65B9246B6CA :

To show the associated public key, run this command, replacing with the GPG key ID from the previous step:

Add a GPG key to your account

To add a GPG key to your user settings:

1. Sign in to GitLab.
2. In the top-right corner, select your avatar.
3. Select Edit profile.
4. On the left sidebar, select GPG Keys ( ).
5. In Key, paste your public key.

To add the key to your account, select Add key. GitLab shows the key’s fingerprint, email address, and creation date:

After you add a key, you cannot edit it. Instead, remove the offending key and re-add it.

Associate your GPG key with Git

After you create your GPG key and add it to your account, you must configure Git to use this key:

Run this command to list the private GPG key you just created, replacing with the email address for your key:

Copy the GPG private key ID that starts with sec . In this example, the private key ID is 30F2B65B9246B6CA :

Run this command to configure Git to sign your commits with your key, replacing with your GPG key ID:

Sign your Git commits

After you add your public key to your account, you can sign individual commits manually, or configure Git to default to signed commits:

Sign individual Git commits manually:

Add -S flag to any commit you want to sign:

Sign all Git commits by default by running this command:

Verify commits

You can review commits for a merge request, or for an entire project:

1. To review commits for a project:
   1. On the top bar, select Main menu > Projects and find your project.
   2. On the left sidebar, select Repository > Commits.
2. To review commits for a merge request:
   1. On the top bar, select Main menu > Projects and find your project.
   2. On the left sidebar, select Merge requests, then select your merge request.
   3. Select Commits.

   Identify the commit you want to review. Signed commits show either a Verified or Unverified badge, depending on the verification status of the GPG signature. Unsigned commits do not display a badge:

   

   To display the signature details for a commit, select the GPG badge:

   

   

Revoke a GPG key

If a GPG key becomes compromised, revoke it. Revoking a key changes both future and past commits:

• Past commits signed by this key are marked as unverified.
• Future commits signed by this key are marked as unverified.

To revoke a GPG key:

1. In the top-right corner, select your avatar.
2. Select Edit profile.
3. On the left sidebar, select GPG Keys ( ).
4. Select Revoke next to the GPG key you want to delete.

Remove a GPG key

When you remove a GPG key from your GitLab account:

• Previous commits signed with this key remain verified.
• Future commits (including any commits created but not yet pushed) that attempt to use this key are unverified.

To remove a GPG key from your account:

1. In the top-right corner, select your avatar.
2. Select Edit profile.
3. On the left sidebar, select GPG Keys ( ).
4. Select Remove ( ) next to the GPG key you want to delete.

If you must unverify both future and past commits, revoke the associated GPG key instead.

• Sign commits and tags with X.509 certificates
• Sign commits with SSH keys
• Commits API
• GPG resources:
  • Git Tools — Signing Your Work
  • Managing OpenPGP Keys
  • OpenPGP Best Practices
  • Creating a new GPG key with subkeys (advanced)
  • Review existing GPG keys in your instance

Troubleshooting

Fix verification problems with signed commits

Commits can be signed with X.509 certificates or a GPG key. The verification process for both methods can fail for multiple reasons:

Secret key not available

If you receive the errors secret key not available or gpg: signing failed: secret key not available , try using gpg2 instead of gpg :

If your GPG key is password protected and the password entry prompt does not appear, add export GPG_TTY=$(tty) to your shell’s rc file (commonly

GPG failed to sign the data

If your GPG key is password protected and you receive the error:

If the password entry prompt does not appear, add export GPG_TTY=$(tty) to your shell’s rc file (commonly

Источник

IntelliJ IDEA and Git’s «gpg failed to sign the data»

Today I’ve decided to improve my Github account settings a bit. I thought that it would be nice to add GPG key to it and sign all commits pushed from my computer. Everything worked great until I tried to commit the first change directly from my IntelliJ IDEA.

Introduction

Why even bother with signing commits with GPG key? The most important reason is quite simple — it proves that you are the author of a given commit. Or to be more precise — the key that was used to sign this commit matches the key associated with your account. Github honors signing commits with this pretty lovely badge added to the commit history log.

Signing git commits make even more sense if you use tools like Keybase.io to chat and share files in a secure (encrypted) fashion.

How to sign Git commits?

First of all, you need to have a GPG key. Github’s help page [1] explains in details how to generate a key, as well as how to associate it with your account. I encourage you to read it — it won’t take more than 5 minutes of your time.

Next, you need to configure your Git client to use the key. Depending on your preferences, you might want to set up GPG signing globally, or you can do it locally for a single repository. In my case, I decided to set up signing commits at the global level with the following two commands:

If you use Git from the command line, that is all you have to do. You can create the first commit and push it to Github to see «Verified» badge next to your commit history log entry.

Getting into troubles with IntelliJ IDEA

I assume you also use your IDE’s built-in Git client. I use IntelliJ IDEA daily, and I use its Git client a lot. When I tried to create the first commit after enabling GPG signing, IDEA’s client stopped working, and it started failing with the following error:

I started googling to see what the problem is. It quickly turned out that this is not the IDEA’s problem, but rather Git and GnuPG issue. It fails to sign the commit if Git command is executed without TTY, so GPG cannot prompt to ask you for a password. I’ve quickly found a solution that suggested creating an alias that executes gpg with —batch —no-tty options. I created a script:

Then I added the following block to my .gitconfig file.

The solutions I’ve found promised that in this case IDEA will use gpg-agent that can store the password in the keyring and automatically sign the commit. Well, it didn’t work for me. At least not right away.

Fedora Linux 29 use case

I use Fedora Linux, and it seemed to be a critical factor in this story. I had to went through a few more articles, and I’ve finally found the answer. When I applied the solution that uses —batch —no-tty for the first time, it didn’t take any effect. However, it turned out that gpg-agent works with GPG 2.x. When I run gpg —version I noticed the following:

It revealed that gpg in my system points to version 1.4.23 . Would it mean that there is no GPG 2.x in Fedora Linux? Nope, not really. GPG 2.x is available for Fedora Linux, but as a gpg2 shell command.

When I replaced the initial script with gpg2 — it worked as expected.

I was able to create the first commit from IntelliJ IDEA. The gpg-agent prompted for the password and I was able to store it in the keyring.

UPDATE: —batch —no-tty not needed with GPG2

I just make some experiments and it seems like using intermediate script that adds —batch —no-tty switches is no needed when you use gpg2 with gpg-agent . (At least in my case). My current setup is the following. I have changed the default gpg program to gpg2 in my

Here is my gpg-agent version.

Make sure that gpg-agent daemon is running. You can start it with the following command:

When you create a first signed commit via command line or from IntelliJ IDEA (I’ve checked both cases after removing remembered password from the keyring), gpg-agent will prompt and ask you for a password that can be stored in the keyring.

If you removed remembered GPG key password from the keyring and you want to test if gpg-agent prompts again for the password correctly, remember to shut down the daemon and restart it.

Conclusion

If you are interested in enabling GPG signing of your Git commits, consider checking this step-by-step guide, where you can find even more information about the setup process. Happy hacking!

Did you like this article?

Consider buying me a coffee

Continue reading: «Hexo git deployer removes commits history? Let’s do something about that!»

I have found Hexo a great tool for building a blog and apply many well-known software development principles. One of them is automation. This is why I have decided to integrate this blog with Travis CI to perform a deployment to GitHub pages. It was a great decision, however a few days later I have noticed one significant issue — deploying a new version of the blog from the CI server caused removing all commits from master branch and starting with initial commit over and over again. It took me a while to find working solution to this problem. This blog post explains a simple solution to this problem.

Источник

Introduction

From the Git User Manual:

Git is cryptographically secure, but it’s not foolproof. If you’re taking work from others on the internet and want to verify that commits are actually from a trusted source, Git has a few ways to sign and verify work using GPG.

One-Time Setup on Windows

1. Install Gnu Privacy Guard (GPG)

If you use Git Bash, then you already have GPG at path /usr/bin/gpg .

If you use PowerShell or cmd.exe, then you will need to install GPG. The simplest way to install GPG is with chocolatey:

> choco install -y gpg4win

Alternately, you can download and install from https://www.gpg4win.org/.

2. Generate a Key

The default key length is 2048 bit. 4096 is even better. You’ll be prompted for name and email. You should use the same information that is associated with your GitHub account.

> gpg --default-new-key-algo rsa4096 --gen-key

3. Configure Git to Always Sign

You will need the key ID for this. In the following example from the Git manual, the id is «E1E474F2023B5ABFF8752630BB4».

> gpg --list-keys
C:/Users/jon.doe/AppData/Roaming/gnupg/pubring.kbx
------------------------------------------------
pub   rsa4096 2020-05-24 [SC] [expires: 2022-04-22]
      E1E474F2023B5ABFF8752630BB4
uid           [ultimate] Jon Doe <jon.doe@examppppppplllleeeee.com>

Configure this globally, or set it up one repository at a time by omitting the --global argument. Additionally, configure the GPG.exe to be used by Git.

> git config --global user.signingkey E1E474F2023B5ABFF8752630BB4
> git config --global gpg.program "C:Program Files (x86)GnuPGbingpg.exe"
> git config --global commit.gpgsign true
> git config --global tag.gpgsign true

4. Upload the Key to GitHub

Export the key using that same key id from above.

> gpg --armor --export E1E474F2023B5ABFF8752630BB4

This will display your PGP Public Key Block. Copy the text, beginning with -----BEGIN PGP PUBLIC KEY BLOCK-----  and ending with -----END PGP PUBLIC KEY BLOCK-----.

Open https://github.com/settings/keys, click the «New GPGP Key» button, and then paste and save the copied public key.

One-Time Setup on Linux and Mac

Please see GPG2 (GnuGP 2) Guide, then see step 4 above.

One-Time Setup in Windows Sub-system for Linux (WSL)

As the Alliance deepens its use of pure open source systems, including support for running applications in Linux, some development practices might benefit from running on the Windows Sub-system for Linux (WSL). The following notes were written while using Ubuntu and they assume that the Windows instructions above have already been completed.

Pure Linux-developers probably know these commands or can easily follow along.

1. Install Git

See  Get started using Git on Windows Subsystem for Linux

2. Copy the Key Created in Windows

To reuse the same key that you already configured in Windows, open Ubuntu and run:

$ cp /mnt/c/users/john.doe/AppData/Roaming/gnupg ~/.gnupg -r
$ rm ~/.gnupg/*.lock

3. Configure Git to Always Sign

You will need the key ID for this. In the following example from the Git manual, the id is «E1E474F2023B5ABFF8752630BB4».

$ gpg --list-keys
/home/john.doe/.gnupg/pubring.kbx
------------------------------------------------
pub   rsa4096 2020-05-24 [SC] [expires: 2022-04-22]
      E1E474F2023B5ABFF8752630BB4
uid           [ultimate] Jon Doe <jon.doe@examppppppplllleeeee.com>

Configure this globally, or set it up one repository at a time by omitting the --global argument. Additionally, configure the GPG.exe to be used by Git.

$ git config --global user.signingkey E1E474F2023B5ABFF8752630BB4
$ git config --global commit.gpgsign true
$ git config --global tag.gpgsign true

4. Configure the GPG Agent

original source of instructions

Create a new gpg-agent.conf file by entering the following command in your Bash prompt:

$ cat > ~/.gnupg/gpg-agent.conf <<EOF
default-cache-ttl 34560000
max-cache-ttl 34560000
pinentry-program "/mnt/c/Program Files (x86)/GnuPG/bin/pinentry-basic.exe"
EOF

Now restart the GPG Agent. You might need to close the Ubuntu terminal window as well.

$ gpgconf --kill gpg-agent

5. Switch to Windows GPG If Needed

The instructions above do not always work. If you get a message like this:

error: gpg failed to sign the data
fatal: failed to write commit object

Then try configuring Git to use the Windows version of gpg, instead of using the WSL copy.

$ git config --global gpg.program "/mnt/c/Program Files (x86)/GnuPG/bin/gpg.exe"

Practice

For those who are just starting out with using git commit signatures, we’ve created a simple training repository in Git which you can use to practice:

1. Fork the repository and clone it locally.
2. Make a small change to the test.md  file.
3. Commit it, using the signature process described above.
4. Push your commit to your fork.
5. Create a pull request back to the main repository.
6. Reach out to the Ed-Fi Alliance tech team or a solution architect for help in verifying and accepting the pull request.

Troubleshooting

Need to Sign Previous Commit(s)

If your last commit was not signed, you can use git commit -S --amend --no-edit to fix it. If you have multiple old commits that now need to be signed, you can try rebasing them and amending. See https://stackoverflow.com/a/54987693/30384. 

Error Message: «cannot open ‘/dev/tty'»

Atlassian SourceTree may have a problem with the instructions above, giving you an error message like:

gpg: cannot open '/dev/tty': Device not configured

error: gpg failed to sign the data
fatal: failed to write commit object

To resolve, either Setup GPG to sign commits in SourceTree or disable tty:

echo 'no-tty' >> ~/.gnupg/gpg.conf

Error Message: «No secret key»

If the following error message occurs after attempting a commit:

gpg: skipped "xxxxxxxxxxxxxxxxxx": No secret key
gpg: signing failed: No secret key
error: gpg failed to sign the data
fatal: failed to write commit object

Open a Git Bash session and type find the location of gpg on the command line:

# If using separate install
$ where gpg
C:Program FilesGitusrbingpg.exe

# If using version that comes with Git-bash
$ which gpg
/usr/bin/gpg

Next, set gpg.program to the path returned from the where command:

$ git config --global gpg.program "C:Program FilesGitusrbingpg.exe"

# Or
$ git config --global gpg.program "/usr/bin/gpg"

Error Message: «No agent running»

On rare occasions the commit signing might fail with a message like this:

$ git commit -m "my commit message"
gpg: can't connect to the agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: signing failed: No agent running
error: gpg failed to sign the data
fatal: failed to write commit object

The reason for this failure is not clear. The solution seems to be to run the gpg-agent from the command line, at least temporarily. Assuming you are using Windows, open a new prompt (cmd, PowerShell, or Git-bash — but not a WSL prompt) and run this:

Now return to your IDE or other command prompt and re-try the git commit  command. If it is successful, you might be able to return to the second window and Control-C out of the daemon.

As part of setting up a new laptop recently, I was setting up git commit signing.

Despite having most of my configs in a git repository or
otherwise tracked, I ran into a problem with setting this up.

Here’s the error:

1
2
3

$ git commit
error: gpg failed to sign the data
fatal: failed to write commit object

And the answer (for me):

Make sure the user.signingkey option in your .gitconfig is in the correct format! This is very
silly, but there are some easy ways to get it wrong. First, some correct examples.

Standard long key format (recommended)

1
2
3
4

[user]
    name = Julian Simioni
    email = julian@simioni.org
    signingkey = 0x4CEEB1E5A7FD15E1

That’s 0x followed by the last 16 characters of your key id. At least as of gnupg 2.2.0 its the
standard output of a command like gpg --list-secret-keys

Long key format without the hexidecimal prefix

1
2
3

[user]
    # ...
    signingkey = 4CEEB1E5A7FD15E1

Still 16 characters, but without the prefix clarifying that the value is written in hexidecimal.

Short key format (works, but not recommended)

1
2
3

[user]
    # ...
    signingkey = A7FD15E1

This is the “short” format, consisting of only 8 characters. It works too, and was much more
standard in the past. However its not recommended as its now far too easy to
generate keys that have the same final 8 characters.

DOESN’T WORK: other key lengths

1
2
3

[user]
    # ...
    signingkey = CEEB1E5A7FD15E1

You might be assuming, like I did, that GPG and git would be smart enough to allow you to use any
suffix of your key, much like git allows you to use any unique prefix of a git commit hash. That is
not the case. I suppose it makes sense. Oh well.

Other useful debugging steps

While in my case the issue with my commit signing was simple user error, I did go through quite a
few other debugging steps, and they were helpful in figuring out where the error was not! Here they
are in case they are useful to me again later (quite likely), or others.

Many of these came from this helpful Stackoverflow thread.

Ensure basic encryption works

A simple way to test gpg and your secret key itself is to issue a command like the following:

1

echo "test" | gpg --clearsign

This will send a small bit of text (“test”) to gpg, and have it print out the same text, but with a
plaintext signature attached. If it works, then you know quite a few things are working: gpg
itself, your secret key, whatever method you are using to enter the passkey to your key (if you have
one, which you should!), etc.

GPG Agent settings, or lack thereof

GPG internally uses an “agent” program. Basically, whenever you run gpg, it launches a process in
the background that will stick around. That process is used to remember your passphrase temporarily,
for convenience, and probably other things.

In the past, ensuring the gpg command you run on the command line can communicate with this agent
has been challenging. If you’ve ever seen instructions regarding adding various GPG_AGENT_INFO
environment variables, its an attempt to properly set up this communication channel.

The good news is that as of GnuPG version 2.1.0, none of this is needed. There is now a
“standard” method of connecting to the agent and everything is supposed to just work. Compare the
instructions in the documentation for version 2.0
and the latest version to see
what I mean.

GPG_TTY environment variable

This variable is important to set up. It will help GPG know which terminal it is running on, so
that the prompt to enter your key passphrase is shown in the correct place. Again, from the GnuPG
documentation, this will do the trick:

1
2

GPG_TTY=$(tty)
export GPG_TTY

Handling local terminal and SSH connections gracefully

There’s nothing worse than not being able to use gpg because you SSHed into your computer, and
when you ran gpg, it popped up a dialog box to enter your passphrase on the computer display
itself, rather than in your SSH session.

Fortunately, its easy to tell pinentry, the underlying program responsible for managing passphrase
entry, to do the right thing during SSH sessions.

1
2
3

if [[ -n "$SSH_CONNECTION" ]]; then
    export PINENTRY_USER_DATA="USE_CURSES=1"
fi

This comes from the GnuPG Gentoo Wiki article.

Pretty fancy.

Коммиты подписываются gpg. При попытке сделать коммит (или мерж-коммит, как на скрине) с помощью gui в PhpStorm выходит ошибка:

gpg failed to sign the data
failed to write commit object

В логах PhpStorm:

2021-10-07 12:32:35,737 [8688771] INFO — 4idea.branch.GitMergeOperation — starting
2021-10-07 12:32:35,737 [8688771] INFO — 4idea.branch.GitMergeOperation — next repository: \wsl$Ubuntu-20.04homeuserprojects*********скрыл**********
2021-10-07 12:32:35,797 [8688831] INFO — #git4idea.commands.GitHandler — [*********скрыл**********] git -c core.quotepath=false -c log.showSignature=false merge master
2021-10-07 12:32:35,837 [8688871] INFO — #git4idea.commands.GitHandler — error: gpg failed to sign the data
2021-10-07 12:32:35,837 [8688871] INFO — #git4idea.commands.GitHandler — fatal: failed to write commit object
2021-10-07 12:32:35,857 [8688891] INFO — 4idea.branch.GitMergeOperation — Unknown error. {128}

Предполагаю, это из-за того, что PhpStorm не может отобразить форму для ввода пароля.

При этом, если буду комитить через консоль PhpStorm, отлично работает:

Так же, если в консоли ввести пароль, например:
echo "test" | gpg --clearsign

Откроется сессиия, и в PhpStrom можно будет какое-то время пользоваться gui git. Пока не закроется сессия, чтобы нужно было ввести заново пароль.

Еще замечание, что такая ошибка возникает для проектов, которые расположены внутри файловой системы WSL. Если проект будет на хостовой Windows, подпись работает штатно.

Конфигурация git:

Windows 10 pro.
PHPStorm 2021.2.2

> wsl —list —verbose
Ubuntu-20.04 Running 2

Почему возникает какая ошибка? Как починить?