5 ms·

have you seen the git smudge and clean filters? they provide a way to perform scripts like this automatically on commit and checkout.

ukd1 13y ago
No, but that sounds awesome! Just looking for examples :)
- heavenlyhash 13y ago
  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
I'll put in a plug for my project, git-crypt, which implements transparent file encryption in git using smudge/clean filters: https://www.agwa.name/projects/git-crypt/ https://www.agwa.name/projects/git-crypt/ Be careful with some of the other git encryption projects out there - most of them get the cryptography wrong, by using either ECB mode or CBC mode with a fixed IV.
- ukd1 13y ago
  This looks cool, the only thing I don't like is that it uses (from what I understand) a single key, not one per developer. Is that planned at all?
  - agwa 13y ago
    Yes, it is planned. I have most of the design figured out and just need to work out a few issues with revoking a developer's access. You're the first person to ask specifically about this feature, which is good motivation to take it off the back burner :-). In the meantime, you can accomplish this by storing the git-crypt key in the repository, but encrypted using GPG with multiple recipients (much like your approach). Then you wrap `git-crypt init` in a script that first decrypts the key using GPG before feeding it to `git-crypt init`. To add a new developer, you just re-encrypt the git-crypt key with an additional recipient.

ukd1 13y ago

No, but that sounds awesome! Just looking for examples :)

heavenlyhash 13y ago
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

I'll put in a plug for my project, git-crypt, which implements transparent file encryption in git using smudge/clean filters: https://www.agwa.name/projects/git-crypt/ https://www.agwa.name/projects/git-crypt/ Be careful with some of the other git encryption projects out there - most of them get the cryptography wrong, by using either ECB mode or CBC mode with a fixed IV.

ukd1 13y ago
This looks cool, the only thing I don't like is that it uses (from what I understand) a single key, not one per developer. Is that planned at all?
- agwa 13y ago
  Yes, it is planned. I have most of the design figured out and just need to work out a few issues with revoking a developer's access. You're the first person to ask specifically about this feature, which is good motivation to take it off the back burner :-). In the meantime, you can accomplish this by storing the git-crypt key in the repository, but encrypted using GPG with multiple recipients (much like your approach). Then you wrap `git-crypt init` in a script that first decrypts the key using GPG before feeding it to `git-crypt init`. To add a new developer, you just re-encrypt the git-crypt key with an additional recipient.