Introduction
If you’re a fellow enthusiast of GPG signing with Git like me, you’ve likely encountered the frustrating error message “gpg failed to sign the data” that goes something like this:
git commit -m "example commit"
error: gpg failed to sign the data
fatal: failed to write commit object
Fear not, for I’m here to share this tutorial on the process of resolving this error. By the time you finish reading, you’ll not only understand the root cause of this issue but also be equipped with the know-how to fix it and ensure the security of your signed commits. Let’s get started on fixing “error: gpg failed to sign the data”.
Stumbling Upon The Error
Picture this: you’ve completed a big code change and you’re all set to make a meaningful commit, and out of nowhere, the dreaded “gpg failed to sign the data” error makes an appearance. It feels like a roadblock that hinders your progress. But fret not, because I’ve been there, and I’ve got a comprehensive solution to share with you.
Troubleshooting Steps
Step 1: Get more details
When this error graced my git commit, I decided to get more information to determine what was preventing my git commits from working. The first step was to tap into the logs generated by the git command itself:
GIT_TRACE=1 git commit -m "example commit"
As you can see above, I added GIT_TRACE=1
to the prefix of the command. This helps to debug the error and get more valuable information.
Step 2: Decipher The Error
After checking the git logs, I was able to see where the commit failed, which is the last command that was posted in the logs:
GIT_TRACE=1 git commit -m "example commit"
09:15:24.335401 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/bin/git
09:15:24.336048 exec-cmd.c:238 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/bin
09:15:24.337183 git.c:460 trace: built-in: git commit -m 'initial sast scanning'
09:15:24.346310 run-command.c:655 trace: run_command: gpg --status-fd=2 -bsau ABCDEFG123456789
error: gpg failed to sign the data
fatal: failed to write commit object
It seems git was failing with the command gpg --status-fd=2 -bsau ABCDEFG123456789
. I can tell this is the problem because it’s the last command to run before the error message.
Step 3: Finding The Root Issue
Now that we have the command that’s failing, we need to know why it’s failing, so I ran the command:
gpg --status-fd=2 -bsau ABCDEFG123456789
And with that, we now have the root issue:
[GNUPG:] KEYEXPIRED 1689202123
[GNUPG:] KEY_CONSIDERED 4FC567899645077A91B11234ABCDEFG123456789 3
gpg: skipped "ABCDEFG123456789": Unusable secret key
[GNUPG:] INV_SGNR 9 ABCDEFG123456789
[GNUPG:] FAILURE sign 54
gpg: signing failed: Unusable secret key
The “KEYEXPIRED” status was an undeniable giveaway, signifying that the GPG key had expired. This discovery brought me to the crux of the matter.
Step 4: Updating the expiration date of the GPG key
With the root cause identified, it was time to take action. I began by listing my GPG keys:
gpg --list-keys
This isn’t necessary, but it’s nice to get a little more information, like when the key expired. Here’s an example of my output:
gpg --list-keys
/Users/jerry/.gnupg/pubring.kbx
-------------------------------------
...
...
# edited to remove other keys
...
...
pub rsa4096 2022-07-12 [SC] [expired: 2023-07-12]
4FC567899645077A91B11234ABCDEFG123456789
uid [ expired] Jerry Warren <email>
Sure enough, there’s the key that expired, and it had expired the same day. This is probably the case for you as well if you use git quite a bit.
Next, I started the process of updating the expiration date. To do this, I needed to edit the key:
gpg --edit-key 4FC567899645077A91B11234ABCDEFG123456789
I received a gpg>
prompt and types expire
to update the expiration date of the GPG key
gpg> expire
Now I can set the timeframe for the expiration. The steps are pretty easy to figure out:
Changing expiration time for the primary key.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for?
You can update the expiration to whatever you like, but for here I decided to do two years. After pressing enter, I was asked to verify my choice:
Key expires at Tue Jul 11 09:17:23 2025 +03
Is this correct? (y/N)
If looks correct, so I typed y
and pressed enter.
Next, I was asked if I wanted to trust the user, which is me, so of course I do:
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision?
I pressed 5
and then pressed enter.
Now the expiration date has been updated.. but there’s still one more thing to do and that’s saving my changes. I typed save
and pressed enter:
gpg> save
Full Example
Here’s a complete example of resolving the issue with a two-year expiration:
gpg --edit-key 4FC567899645077A91B11234ABCDEFG123456789
gpg (GnuPG) 2.4.0; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa4096/1111E0F8C579999
created: 2022-07-12 expired: 2023-07-12 usage: SC
trust: ultimate validity: expired
ssb rsa4096/ABCDEFG123456789
created: 2022-07-12 expired: 2023-07-12 usage: E
[ expired] (1). Jerry Warren <email>
gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 2y
Key expires at Tue Jul 11 09:17:23 2025 +03
Is this correct? (y/N) y
sec rsa4096/1111E0F8C579999
created: 2022-07-12 expires: 2025-07-11 usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/ABCDEFG123456789
created: 2022-07-12 expired: 2023-07-12 usage: E
[ultimate] (1). Jerry Warren <email>
gpg: WARNING: Your encryption subkey expires soon.
gpg: You may want to change its expiration date too.
gpg> trust
sec rsa4096/ABCDEFG123456789
created: 2022-07-12 expires: 2028-07-11 usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/1111E0F8C579999
created: 2022-07-12 expired: 2023-07-12 usage: E
[ultimate] (1). Jerry Warren <email>
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
sec rsa4096/ABCDEFG123456789
created: 2022-07-12 expires: 2025-07-11 usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/1111E0F8C579999
created: 2022-07-12 expired: 2023-07-12 usage: E
[ultimate] (1). Jerry Warren <email>
gpg> save
Verifying Your Work
Now that my changes have been made, I want to verify the changes worked and my key is updated. First, I checked gpg:
gpg --list-keys
Of course, my key is now updated:
gpg --list-keys
/Users/jerry/.gnupg/pubring.kbx
-------------------------------------
...
...
# edited to remove other keys
...
...
pub rsa4096 2022-07-12 [SC] [expired: 2025-07-11]
4FC567899645077A91B11234ABCDEFG123456789
uid [ expired] Jerry Warren <email>
The Conclusion
If you find yourself facing the same challenge, remember that you’re not alone. Follow my footsteps, dive into the logs, and unearth the underlying cause of the error. With a touch of determination and a sprinkle of understanding, you too can breathe life back into your expired keys and experience the triumph of seamless and secure commits.
I’d love to hear about your own experiences and any additional troubleshooting steps you took. Feel free to share your journey in the comments below. After all, we’re in this together, navigating the complexities of GPG key management, and emerging victorious, one signed commit at a time.
If you just want to send some kudos, you can always buy me a cup of coffee:
Leave a Reply