-
Notifications
You must be signed in to change notification settings - Fork 477
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add del-gpg-user
to delete (and re-encrypt) repository
#47
Comments
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 Something that Perhaps rather than (or as a simpler step before) adding 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. |
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. |
👍 |
1 similar comment
👍 |
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. |
@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. |
@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. |
@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. |
Perpetual grant of access is certainly a security issue, so goes to the corresponding section. Based on the discussion in AGWA#47
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 |
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. |
So here's what I did to re-encrypt files to remove a user:
Hope that help until we get there 😅 |
I have a suggestion for the implementation that may work.
It might be possible to use the existing support for multiple keys to achieve the desired user access revocation (for the future commits only of course). Consider the following steps:
All new or updated files would be encrypted with the new default key. Would this work? |
Based on phunehehe's comment I hacked together a script to get the job done. You can find it here https://gist.github.com/glogiotatidis/e0ab45ed5575a9d7973390dace0552b0 |
Any updates on this? |
Any thoughts on using the oft-misunderstood-and-avoided-but-very-powerful-and-actually-not-scary-at-all feature |
I'd like to poke the proverbial bear. Bump. 😈 |
For some odd reason, I now need this feature. 😛 Halp! |
Bump |
I wrote a bash script that will rekey the repo on-demand using a remote list of users (currently, JSON in S3). Use The script will take care of getting GPG keys from public sources, signing them, backing up and restoring encrypted files, plus all of the cleanup, init, and git work required. It even does it all in a branch, if things go wrong just run |
I also need this feature - be able to revoke access to encrypted files. |
So, what is the best approach ? Use symmetric key and rotate? |
I am also interested in what the recommended approach is. |
I have seen this gist from @glogiotatidis do we have another approach to remove GPG key added ? |
slightly off-topic but since i'm mentioned: For new repos we have experimenting with keybase's encrypted git and teams and so far works OK. |
@glogiotatidis thanks for the feedback |
I found simpler way to rotate the key. Simpler as in "closer to the basics" :).
About This is the key used by git-crypt to encrypt files. This file only exist after you execute How to get a new P. S. Or better use another empty repository for a new encryption key. |
FWIW, I found a procedure to rotate the symmetric key that doesn't need poking at hidden git-crypt dependent files:
After updating, just git-crypt unlock with the new key. |
I reworked a little the script made by @glogiotatidis from the initial proposal of @phunehehe (for endling the case of absence of encrypted files, expired keys etc.). The resulting extended version is available on https://gist.github.com/Falkor/7b29f16f5f79404fe41476be0d992783 |
``` # Dejar los secretos en claro antes de realizar el proceso git crypt unlock # Eliminar el acceso a la clave con mi llave privada. git rm .git-crypt/keys/default/0/0EF5D686FC13831A54874C275FC681B4822DABB0.gpg # Eliminar la clave simétrica con la que se está cifrando la información. rm .git/git-crypt/keys/default # Hacer commit hasta ahora git commit # Cambiar los secretos en los archivos privados. $EDITOR secreto # Generar una nueva clave de cifrado git crypt init # Agregar a las personas que necesitan agregarse for key in key1 key2 key3; do git crypt add-gpg-user $key done # La persona que recibe el código debe bloquear el repositorio [1] git crypt lock git pull ``` [1]: AGWA/git-crypt#47
I rework @Falkor rework to make the script safer, compliant with shellcheck: |
@thomsh Many thanks for the rework! I merged your contributions into my gist. |
I created a script that only updates the key and the encrypted files. This should be used after removing 1 or more collaborators gpg files. https://gist.github.com/bartv2/7e1c127d6af397bc0e4da6d11fb7ea6c |
Hey, thank you all for the hints. # Make a branch for these changes
git checkout -b fix-git-crypt
# Unlock repo and preserve all the secrets into unencrypted-secrets directory
git-crypt unlock
mkdir -p unencrypted-secrets
git-crypt status -e | while read s f; do
mkdir -p "unencrypted-secrets/$(dirname "$f")"
cp -a "$f" "unencrypted-secrets/$f"
done
# Lock repo and remove all the secrets and git-crypt configuration
git-crypt lock
git-crypt status -e | while read s f; do
git rm "$f"
done
git rm -r .git-crypt/
rm -rf .git/git-crypt
git commit -m "cleanup old secrets"
# Setup new git-crypt configuration
git crypt init
gir-crypt add-gpg-user ...
gir-crypt add-gpg-user ...
gir-crypt add-gpg-user ...
# Move secrets back in places
cp -r unencrypted-secrets/* .
git add .
git rm -rf unencrypted-secrets
git commit -m "add new secrets"
# Lock repo and checkout to the previous branch
git-crypt lock -a
git checkout -
# Squash and merge our branch
git merge -X theirs --squash fix-git-crypt
git commit I hope someone will find these steps useful. |
FYI: I've updated git-crypt-rm-gpg-user.sh to support multiple git-crypt keys |
Any progress on this @AGWA? In the meantime, are the comments from #47 (comment) and #47 (comment) the recommended best practice? |
I am so confused! |
To avoid multiple commits and moved around or temporally removed files the following worked for me:
|
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.
The text was updated successfully, but these errors were encountered: