git-crypt-rekey.sh

#!/bin/bash

# Unlock the directory, we need the unencrypted versions of the files
git crypt unlock

# Re-initialize git crypt, generating a new key
rm .git/git-crypt/keys/default
git crypt init

# Make the key available to the current users
KEY_FILES=`ls .git-crypt/keys/default/0/`
for f in $KEY_FILES; do
  gpg -e --always-trust -r ${f%.gpg} < .git/git-crypt/keys/default > .git-crypt/keys/default/0/$f
done

# Re-encrypt the files with the new key
ENCRYPTED_FILES=`git crypt status -e | colrm 1 14`
git rm --cached $ENCRYPTED_FILES
git add $ENCRYPTED_FILES

Thank you very much for providing this script. It helped re-encrypt the repo after the symmetric key had been compromised.

While this works as intended, it should be pointed out that this will lead to losing unencrypted history access with errors like this:

git-crypt: error: encrypted file has been tampered with!
error: external filter '"/usr/bin/git-crypt" smudge' failed 1
error: external filter '"/usr/bin/git-crypt" smudge' failed
fatal: example.txt: smudge filter git-crypt failed

It seems like this is a general shortcoming of git-crypt, because rotating the symmetric key should be a pretty standard key, after all this should be done whenever an asymmetric key is removed, otherwise, the whole notion of removing keys is quite pointless.

Hi @cfra ,

Thank you for your message, but this is a fork as a backup of the original script https://gist.github.com/bartv2/7e1c127d6af397bc0e4da6d11fb7ea6c and the author takes their credit.

The problem you're facing may be relevant to changes of file paths. Are you sure the file example.txt still does exist. Would you have the same issue when working on a fresh clone of your repository?

I'd suggest you to raise/find the issue from the official page https://github.com/AGWA/git-crypt/issues.

Best luck.

PS: I migrated my repositories to sops (https://github.com/mozilla/sops) which is not perfect, but I don't really need to deal with gpg stuff within the repository ;)