I recently switched a repository from git-gpg to git-remote-grcypt, one of the reasons being better support by git-annex (so yes, that makes up a gcrypt::rsync://
git-remote for a git-annex
repository, that itself saves encrypted blobs with git-annex special remotes … because why not).
A problem I have, is that once in a while a random pull
or push
operation fails with the quite frustrating:
| gcrypt: Decrypting manifest
| gpg: Signature made Thu 04 Sep 2021 08:59:18 AM EDT
| gpg: using RSA key DEADBEEF122345678DEADBEEF122345678
| gpg: BAD signature from "Yours Trully <yours.truly@example.com>" [ultimate] | gcrypt: Failed to decrypt manifest!
I haven't yet managed to fully fix it (my current guess is that git-annex is trying to do too many things concurrently), but at least I managed to repair it!
Addendum — Sat, 02 Oct 2021: Indeed the problem seems to come from concurrency, I've been running git-annex-sync
with --jobs=1
for more than 10 days and I haven't seen the “bad signature” error.
I didn't find any significant help online and, of course, “bad signatures” should not just be dismissed, but in the meantime, here is the workaround in case it helps:
We find the manifest's filename from the git-remote-gcrypt
script itself:
$ grep -E ^Manifestfile $gcrypt_remote_script
Manifestfile=91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
(in my case $gcrypt_remote_script
is "/nix/store/0wdr7av1zwbb2354a0rakl5rr156r0y7-git-remote-gcrypt-1.4/bin/.git-remote-gcrypt-wrapped"
but it is also on GitHub).
Then, basically, get it, decrypt it, and re-encrypt it:
$ scp $git_host/$gcrypt_repo/$Manifestfile .
$ gpg -d $Manifestfile > manifest-decrypted
$ gpg --encrypt -r yours.truly@example.com \
-u yours.truly@example.com --sign manifest-decrypted
Worth checking that the new signature is good with gpg -d manifest-decrypted.gpg
.
Then, just put it back:
$ scp manifest-decrypted.gpg $git_host:$gcrypt_repo/$Manifestfile
⇒ (Small) Victory! We can push/pull again, and go back to trying to understand the actual problem.