gnupg updates: cannot sign git commits: "signing failed: No secret key"
After yesterday's gnupg updates, I can no longer sign my git commits. When I try to make a commit, I get the following output:
Code:
error: gpg failed to sign the data: |
All keys under both my user and root accounts are still present.
|
I didn't think about checking root keys. They all seem to be there, although I think they're all the keys for my slackpkgplus repositories. Looking in ~/.gnupg for my user, pubring.gpg and secring.gpg both still exist, last modified in late 2022, but for some reason gpg doesn't seem to find them?
|
I had a problem with gpg during the update which stopped generating an error. Looking at the ChangeLog.txt I saw that gpg has been renamed to gpg1 and that /usr/bin/gpg is now a link to the new /usr/bin/gpg2. It was enough for me to manually create this link for everything to work again
|
Ah, I solved it. If I run gpg1 --list-keys it finds the keys. Does anyone know if there's a way I can set up gpg2 to find them? /usr/bin/gpg is already a link to /usr/bin/gpg2 on my system; running either finds none of the keys that gpg1 finds.
In the meantime, I was able to solve the git commit issue by setting: Code:
git config --global gpg.program "/usr/bin/gpg1" |
Both gpg1 and gpg2 share the same public keyring (~/.gnupg/pubring.gpg). Both gpg1 --list-keys and gpg2 --list-keys should show the same public keys.
However, from gnupg 2.1 onwards, storage of private keys were moved to individual files in ~/.gnupg/private-keys-v1.d/ rather than ~/.gnupg/secring.gpg. if you run gpg1 --list-secret-keys or gpg2 --list-secret-keys you'll possibly get different results. Now, the first time you run gpg2 it'll check for the existence of a file ~/.gnupg/.gpg-v21-migrated, if that file doesn't exist it will copy all the secret keys in secring.gpg into the private-keys-v1.d/ directory and create that file. gpg2 will use this new directory from now on. Now, the awkward bit is that gpg1 will continue to use the old copy in secring.gpg and as this 'migration' is a one time only event, any key changes you make with one version or the other will cause them to diverge. This is why I suggest using one version or the other and never both. Theoretically removing the .gnupg-v21-migrated checkfile should allow one to force a re-migration, but you'll likely lose any changes made with gpgv2 and it might be better just exporting and reimporting your keys manually. |
Looks like that was the problem; the .gpg-v21-migrated file existed but nothing had been migrated into private-keys-v1.d. I hadn't made any changes with gpg2, so I removed that file and the re-migration worked. Thanks for the help!
|
Is there any real reason to have both gpg2 and gpg1 around? I only use gpg2 and am thinking of uninstalling gpg1.
|
Quote:
Quote:
|
Quote:
|
Quote:
When I say “(very) old keys”, I mean the kind of keys produced by PGP 2.x, in the middle of the 90s. If you do have such files or emails around, the best thing to do would be to use gpg1 once to decrypt them, and then re-encrypt them with a modern key. |
I am facing some problems. Can I ask a question? Is there anyone who can help me complete my thesis? But I have found the answer to this; it is a website called Academicized. They are a writing help https://academized.com/pay-for-thesis website. They help us with our writing work. I have used them to write my thesis; they helped me so well, and the price was also very affordable. If you also need someone whom you can pay for your thesis, you can get their help.
|
Quote:
If your issue isn't exactly the same as this one, though, you might find more interaction by starting a new thread; I imagine people are less inclined to click on one marked 'solved'. |
All times are GMT -5. The time now is 10:58 AM. |