Skip to content
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

Request for clarification: Access to historical secrets after revocation #653

Closed
MathiasPius opened this issue Apr 14, 2021 · 3 comments · Fixed by #654
Closed

Request for clarification: Access to historical secrets after revocation #653

MathiasPius opened this issue Apr 14, 2021 · 3 comments · Fixed by #654

Comments

@MathiasPius
Copy link
Contributor

MathiasPius commented Apr 14, 2021

I wasn't able to find an answer to this question on the website or the documentation, and was not able to decipher definitively one way or the other from the source code, so I pose my question here:

What, if any, measures does git-secret take to prevent post-revocation access to historical secrets in the git history?

Assuming a user has access to a public repository, has been included in the keyring and that the secrets in the repository have been re-hidden using this keyring. If the user is then "killed", what prevents them from checking out an older reference and accessing the secrets as they were at that point?

I agree that the example may be a little contrived, given the decentralized nature of git which means that:

  • Even if steps are taken within the remote to rebase or filter out the older keyrings and encrypted secrets, a copy may still exist on their local machine
  • That in most cases a repository containing secrets like this will likely be private in some form, meaning the revocation in most cases would be coupled with restricting access to the repository itself.

But I did find it somewhat concerning that this was not addressed at all, as far as I could tell. git-crypt for example has a very clear disclaimer for this type of scenario, and the lack of it might provide a false sense of security for users of git-secret, which might skew decision-making when choosing an in-tree encryption method.

@sobolevn
Copy link
Owner

Hi! @MathiasPius this is a great question!

Indeed, we don't have any might to revoke things that was once granted.
So, all granted secrets must be re-newed if you remove someone from a trusted key-ring.

It is surely must be in the "killperson" command docs.

@MathiasPius
Copy link
Contributor Author

Thanks for the quick reply!

The documentation of git-secret-killperson says the following:

This command removes the keys associated with the selected email addresses from the keyring. If you remove a keypair’s access with git-secret-killperson, and run git-secret-reveal and git-secret-hide -r, it will be impossible for given users to decrypt the hidden files.

... Which is technically true for the files as they exist at the HEAD of the repository, but I believe it could benefit from a clarification regarding historical secrets, although I'll admit I'm not entirely sure of a formulation. Perhaps an addendum like this?

Using git-secret-killperson and re-encrypting the secrets does not prevent a user from extracting secrets that they have previously had access to. The old keyrings and the secrets encrypted with them will still be readable by the user in the git history. This means that any secrets that the user has had access to at any time must be changed and re-encrypted after their key has been removed from the keyring.

@sobolevn
Copy link
Owner

👍

sobolevn pushed a commit that referenced this issue Apr 14, 2021
…and is not readable by a user after having been removed from the repository's keyring (#654)

* Closes #653

Add security disclaimer for git-secret-killperson specifying what is and is not readable by a user after having been removed from the repository's keyring

* Document addition of disclaimer in changelog
@sobolevn sobolevn mentioned this issue May 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants