4 ms·

Check out the email from Michael J Gruber on the git mailing list: http://git.661346.n2.nabble.com/Transparently-encrypt-repository-contents-with-GPG-td2470145.

Check out the email from Michael J Gruber on the git mailing list: http://git.661346.n2.nabble.com/Transparently-encrypt-repository-contents-with-GPG-td2470145.html http://git.661346.n2.nabble.com/Transparently-encrypt-reposi... There's a fairly complete example there, plus discussion. (It's worth mentioning that many of the git maintainers find this to be an odd use of the git filters feature, because it doesn't let you diff things. But of course, that's not the point.)

agwa 13y ago
The first example there uses gpg, which is a very sub-optimal approach because gpg uses non-deterministic encryption. That means that git always thinks the file has changed, because every invocation of the filter produces a different output. A later example tries to fix this by using deterministic encryption with openssl instead of gpg, but it's insecure because it accomplishes the determinism by using either ECB mode or CBC mode with a fixed IV. The proper solution is to use a real deterministic encryption scheme (such as CTR mode with the nonce derived from a HMAC of the plaintext), and also use a diff filter so git diffs work. Not only does git work properly, it's actually secure too! My project, git-crypt[1], works this way. [1] https://www.agwa.name/projects/git-crypt/ https://www.agwa.name/projects/git-crypt/
- ukd1 13y ago
  GPG is fine, if you don't decrypt and then encrypt unless you're doing an update. So, why would it matter?
  - agwa 13y ago
    If you're using GPG manually, as described in your article, then it's fine, but when you're using git filters you have no control over when encryption/decryption takes place and when it doesn't. Whenever a file is checked out from the index to the working tree, git invokes the the smudge filter, and whenever git needs to check if the file in the working tree has changed (as from `git status`), it invokes the clean filter, even if you haven't actually changed the file in the working tree[1]. If the results from the clean filter are different from what's in the index, git thinks the file has changed. That means the clean filter had better produce the same output if the working tree version hasn't actually changed. GPG doesn't satisfy that requirement. [1] newer versions of git do some caching here, so the clean filter might not always be invoked, but it's still invoked often enough to cause problems

agwa 13y ago

The first example there uses gpg, which is a very sub-optimal approach because gpg uses non-deterministic encryption. That means that git always thinks the file has changed, because every invocation of the filter produces a different output. A later example tries to fix this by using deterministic encryption with openssl instead of gpg, but it's insecure because it accomplishes the determinism by using either ECB mode or CBC mode with a fixed IV. The proper solution is to use a real deterministic encryption scheme (such as CTR mode with the nonce derived from a HMAC of the plaintext), and also use a diff filter so git diffs work. Not only does git work properly, it's actually secure too! My project, git-crypt[1], works this way. [1] https://www.agwa.name/projects/git-crypt/ https://www.agwa.name/projects/git-crypt/

ukd1 13y ago
GPG is fine, if you don't decrypt and then encrypt unless you're doing an update. So, why would it matter?
- agwa 13y ago
  If you're using GPG manually, as described in your article, then it's fine, but when you're using git filters you have no control over when encryption/decryption takes place and when it doesn't. Whenever a file is checked out from the index to the working tree, git invokes the the smudge filter, and whenever git needs to check if the file in the working tree has changed (as from `git status`), it invokes the clean filter, even if you haven't actually changed the file in the working tree[1]. If the results from the clean filter are different from what's in the index, git thinks the file has changed. That means the clean filter had better produce the same output if the working tree version hasn't actually changed. GPG doesn't satisfy that requirement. [1] newer versions of git do some caching here, so the clean filter might not always be invoked, but it's still invoked often enough to cause problems