[git] error: gpg failed to sign the data

[peterlobster]

I switched systems, but for some reason, I can't get git to work. Everything else seems to work though, which is what's strange. Even SSH. Maybe because this is running GNOME Seahorse as a Flatpak? However that wouldn't make sense since gpg is located outside the Flatpak.

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

$ gpg --card-status
Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00
Application ID ...: D276000124010000xxxxxxxxxxxxxxxxxxx
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: Yubico
Serial number ....: xxxxxxxx
Name of cardholder: Peter
Language prefs ...: en
Salutation .......: 
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 5 5 5
Signature counter : 2951
KDF setting ......: off
UIF setting ......: Sign=off Decrypt=off Auth=off
Signature key ....: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
      created ....: 2021-09-17 20:10:38
Encryption key....: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
      created ....: 2021-09-17 20:11:38
Authentication key: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
      created ....: 2021-09-17 20:12:14
General key info..: sub  rsa4096/0x3B04260A44Axxxxx 2021-xx-xx Peter <xxxx@xxxx.com>
sec#  rsa4096/0xFC3B0Exxxxxxxxxx  created: 2021-xx-xx  expires: never     
ssb>  rsa4096/0x3B0426xxxxxxxxxx  created: 2021-xx-xx  expires: 2022-xx-xx
                                  card-no: 0006 143xxxxx
ssb>  rsa4096/0xA230D2xxxxxxxxxx  created: 2021-xx-xx  expires: 2022-xx-xx
                                  card-no: 0006 143xxxxx
ssb>  rsa4096/0x046F13xxxxxxxxxx  created: 2021-xx-xx  expires: 2022-xx-xx
                                  card-no: 0006 143xxxxx

$ cat ~/.gitconfig
[user]
    name = Peter
    email = xxxx@xxxx.com
    signingkey = 0x3B0426xxxxxxxxxx
[gpg]
    program = /usr/bin/gpg
[credential]
    helper = cache
[commit]
    gpgsign = true

$ cat ~/.gnupg/gpg.conf
# Use AES256, 192, or 128 as cipher
personal-cipher-preferences AES256 AES192 AES
# Use SHA512, 384, or 256 as digest
personal-digest-preferences SHA512 SHA384 SHA256
# Use ZLIB, BZIP2, ZIP, or no compression
personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed
# Default preferences for new keys
default-preference-list SHA512 SHA384 SHA256 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed
# SHA512 as digest to sign keys
cert-digest-algo SHA512
# SHA512 as digest for symmetric ops
s2k-digest-algo SHA512
# AES256 as cipher for symmetric ops
s2k-cipher-algo AES256
# UTF-8 support for compatibility
charset utf-8
# Show Unix timestamps
fixed-list-mode
# No comments in signature
no-comments
# No version in output
no-emit-version
# Disable banner
no-greeting
# Long hexidecimal key format
keyid-format 0xlong
# Display UID validity
list-options show-uid-validity
verify-options show-uid-validity
# Display all keys and their fingerprints
with-fingerprint
# Display key origins and updates
#with-key-origin
# Cross-certify subkeys are present and valid
require-cross-certification
# Disable caching of passphrase for symmetrical ops
no-symkey-cache
# Enable smartcard
use-agent
# Disable recipient key ID in messages
throw-keyids
# Group recipient keys (preferred ID last)
#group keygroup = 0xFF00000000000001 0xFF00000000000002 0xFF3E7D88647EBCDB
# Keyserver URL
#keyserver hkps://keys.openpgp.org
#keyserver hkps://keyserver.ubuntu.com:443
#keyserver hkps://hkps.pool.sks-keyservers.net
#keyserver hkps://pgp.ocf.berkeley.edu
# Proxy to use for keyservers
#keyserver-options http-proxy=http://127.0.0.1:8118
#keyserver-options http-proxy=socks5-hostname://127.0.0.1:9050
# Verbose output
#verbose
# Show expired subkeys
#list-options show-unusable-subkeys

$ cat ~/.gnupg/.gpg-agent
enable-ssh-support
ttyname $GPG_TTY
default-cache-ttl 60
max-cache-ttl 120
pinentry-program /usr/bin/pinentry

$ uname -a
Linux N7 6.1.0-gentoo #1 SMP PREEMPT_DYNAMIC Sun Jan  8 13:42:09 PST 2023 x86_64 Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz GenuineIntel GNU/Linux

[Paraphraser]

Not 100% sure about this but if the expiration dates on your sub keys really are 2022 then that might explain it. Maybe try signing a text file from the gpg CLI and see if you get more info.

Something like

$ ls -l >test.txt
$ gpg --armor --default-key $GITHUBKEYID --output test.sig --detach-sign test.txt

[peterlobster]

@Paraphraser Thanks for the help. Yeah, that works. I always rotate my keys every year on 09-17. So they're set to expire 09-17-2023.

[iandstanley]

FYI as an alternative …You don’t need to rotate your keys if you don’t want to You can edit your keys and move back the expiry date and just republish your public key and resend your private key to your Yubikey On 10 Jan 2023, at 13:06, The Lobster @.***> wrote: @Paraphraser Thanks for the help. Yeah, that works. I always rotate my keys every year on 09-17 every year. So they're set to expire 09-17-2023.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Paraphraser]

@peterlobster - I'm sorry but I don't quite understand your answer.

Are you saying:

1. You normally rotate on 09-17 and did so on 09-17-22 but forgot to push the renewed keys to your YubiKey, that you have just done the push, and now everything works? Or,

2. The keys on your YubiKey were pushed on 09-17-22, so the lines in your --card-status output which suggested 2022 expiration dates:

   ssb>  …  expires: 2022-xx-xx

   were either wrong or somehow still "correct" but not the actual cause of your problem, but that everything now works anyway either because the problem just went away by itself or because you found some other explanation?

Up until now, I've had no reason to distrust --card-status output so I'd really like to understand whether there is, in fact, a situation where updated keys can return incorrect expiry dates? I hope that makes sense.

[peterlobster]

@Paraphraser I apologize. It must have been an issue of mistaken outputs. I seem to have copied the output from a previous backup (I keep lots of backups) I had imported which was taken prior to me renewing the keys. By the time I checked them again, that problem was corrected, hence the output I sent.

Man, that caused quite the confusion, lol. My bad guys.

Anyways, I did get it fixed. I think it may have had something to do with the Seahorse Flatpak and the way it's all set up to handle GPG/SSH.