Yesterday upon setting up an hybrid
encrypted rsync backend (with git-remote-annex
) support, I stumbled around this bug. The annex remote would corrupt itself and no amount of git annex repair
would fix it, unfortunately.
$ git annex push
push <remote>
Full remote url: annex::<remote-uuid>?encryption=hybrid&rsyncurl=<url>&type=rsync
gpg: zlib inflate problem: invalid block type
user error (gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","13","--decrypt"] exited 2)
git-annex: Failed to download GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
Full remote url: annex::<remote-uuid>?encryption=hybrid&rsyncurl=<url>&type=rsync
gpg: zlib inflate problem: invalid block type
user error (gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","13","--decrypt"] exited 2)
git-annex: Failed to download GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
Pushing to <remote> failed.
failed
push: 1 failed
I then started to investigate the temporary files in .git/annex/tmp
and found the aforementionned GITBUNDLE, as well as it's encrypted counterpart.
$ tree .git/annex/tmp/
.git/annex/tmp/
├── GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
└── GPGHMACSHA1--f2d78638494030b34841f7a30ffb2800816ef839
I wanted to confirm that the file was corrupted for real, so obtained the cipher for my hyrid repository like so:
$ cipher=$(git show git-annex:remote.log | grep 'name=<remote>' | grep -oP 'cipher\=.*? ' | sed 's/cipher=//')
And confirmed the encrypted file was indeed corrupted by decrypting it manually:
$ echo $cipher | base64 -d | gpg -d | tail -c +257 | gpg --batch --passphrase-fd 0 --decrypt .git/annex/tmp/GPGHMACSHA1--f2d78638494030b34841f7a30ffb2800816ef839 > /dev/null
gpg: encrypted with rsa2048 key, ID <gpg-id>, created 1970-01-01
"... <...>"
gpg: encrypted with cv25519 key, ID <gpg-id>, created 1970-01-01
"... <...>"
gpg: AES256.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: zlib inflate problem: invalid block type
I then searched in the annex's directory for the uncorrupted GITBUNDLE to find out that it indeed existed:
$ find . -type f -name "GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49"
./.git/annex/objects/Vg/Mm/GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49/GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
Now that I have a way to get the symmetric cipher and the source file, as well as it's encrypted filename, I can re-encrypt it:
$ echo $cipher | base64 -d | gpg -d | tail -c +257 | gpg --batch --passphrase-fd 0 --output /tmp/GPGHMACSHA1--f2d78638494030b34841f7a30ffb2800816ef839 --symmetric ./.git/annex/objects/Vg/Mm/GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49/GITBUNDLE-s<id>--<remote-uuid>-77e0ff1580b971da4e39b15ba22439d66e3c5729adea2d7df8643438ef900c49
And then upload it to replace the corruped one on the remote.
I then confirmed it was fixed by issuing a git annex sync --content
.
This could be detected and handled directly by
git annex repair
or thegit annex assistant
daemon.I unfortunately have no Haskell knowledge and the barrier to entry seems to big for me to contribute right now.