Add `del-gpg-user` to delete (and re-encrypt) repository

[reedloden]

Need to be able to remove a GPG key for a user and then re-encrypt the repository. Obviously, the user would be able to decrypt old revisions but any new revisions would not be encrypted with the user's key.

[dupuy]

This is definitely an issue that should also be addressed in the documentation - for security to be meaningful it is important for end-users to fully understand the security implications of the use of a tool - and even if there is a del-gpg-user subcommand that re-encrypts the repository, end users need to understand that they need to revoke and regenerate any credentials that were (ever) stored in the repository - and that is something that git-crypt cannot implement itself as revocation/regeneration is entirely outside the Git ecosystem.

Something that del-gpg-user could do to "help" or "encourage" such revocation/regeneration would be to replace all encrypted files with empty ones, but the implications of that need to be examined as it might just make things more confusing for less experienced users.

Perhaps rather than (or as a simpler step before) adding del-gpg-user a better approach might be to add a re-init command that just does the regeneration of encryption key (with optional removal of encrypted files and/or their contents).

Anyhow, I've no experience with Go, but can probably contribute to the documentation a section on the implications of putting credentials or other types of secrets in a git-crypt-enabled repository, and what revocation of access may mean - I'll look at what I could do and try to submit a PR with an outline sometime next week.

[AGWA]

This issue has been on my radar for a while. It's surprisingly complicated, because you have to rotate git-crypt's internal symmetric key and re-encrypt all files with the new symmetric key, in order to preserve confidentiality of future commits. To avoid breaking history, you have to keep around the old versions of the key and use them when dealing with old commits. Fortunately, git-crypt already has the framework for this - it just needs to be wired up, and tested extensively. I suspect that there will be big problems with merging if the key has been rotated on one branch of the merge. So, a lot of the work will be testing how key rotation interacts with various other Git operations. Fortunately, that's something anyone can help with, without having to do any coding.

@dupey you are correct about credentials protected by git-crypt needing to be rotated too, but that's definitely outside the domain of git-crypt, and I don't like the idea of git-crypt automatically truncating files. A discussion in the documentation would definitely be warranted though. Thanks for offering to help with this.

[erikthorselius]

👍

[alexkli]

👍

[redterror]

Just curious - what are the use cases people have in mind for this feature? I had convinced myself I needed it if I wanted to revoke access from a former employee, but after thinking some more, I don't actually need it. In my situation github's access controls + secret rotation are sufficient.

[reedloden]

@redterror git-crypt supports two forms of encryption -- symmetric key and GPG. In the former case (which it sounds like you use), rotation of the key is all you can do. In the latter, you need to be able to remove a user's GPG public key and re-encrypt the entire repository. The user would be able to access old copies of the repository that were encrypted with his/her public key, but any new changes would not be encrypted with his/her GPG public key, so they would be inaccessible.

[dupuy]

@reedloden Technically, a symmetric key is used for encryption of files in every case - it is just that in the second case the symmetric key itself is encrypted with one or more GPG keys and those copies of the encrypted key are committed to the repository, allowing a user whose GPG key was "added" to decrypt the encrypted contents in the repository using nothing more than their private key and the repository itself.

[redterror]

@dupuy - I'm with you on all that, what I was suggesting was that the use-case of a privileged user that becomes unprivileged but still retains repo access at all may be uncommon. In my case removing access at the github level solves the problem entirely.

I get that this is useful out of completeness, it just seems like a scenario that folks may think they need but actually don't. I don't know really know, I'm just suggesting that this may not be all that important in real deployments.

[pfalcon]

With the thoughts in #23 (comment) , I'd like to make a step forward with further progressing git-crypt, by making it be fair about its deficiencies: #72

[geowa4]

This would be a nice feature. I had to jump through some interesting hoops to re-initialize the repo after a coworker left. For my use case, I don't really care about history; the value of the old database password isn't exactly useful.

[phunehehe]

So here's what I did to re-encrypt files to remove a user:

• Make a backup (with decrypted files): cp -r . /path/to/backup
• Save a list of files that are encrypted: git crypt status | grep -v 'not encrypted' > ../encrypted-files.txt
• Make git-crypt forget about itself: rm .git-crypt
• Delete the encrypted files: awk '{print $2}' ../encrypted-files.txt | xargs rm
• Commit (at this point you get a repo without git-crypt stuff)
• Add git-crypt from scratch (init and add-gpg-user)
• Copy the decrypted files from the backup: awk '{print $2}' ../encrypted-files.txt | while read l; do cp /path/to/backup/$l $l; done
• Commit (at this point you are done, but be sure to verify things are properly encrypted before publishing)

Hope that help until we get there 😅