4 ms·

I use gitcrypt to keep sensitive configuration data out of git history, while still being able to diff, log, merge etc those files. It works well for that. Not

by sigil 13y ago

I use gitcrypt to keep sensitive configuration data out of git history, while still being able to diff, log, merge etc those files. It works well for that. Note, gitcrypt uses symmetric encryption and stores the shared key in your gitconfig. It would be nice to use gpg instead for git's "smudge" and "clean" filters, but I can't for the life of me get a sane gpg-agent forwarding setup going, which renders that idea pretty useless. Anyone have suggestions there?

agwa 13y ago
git-crypt author here. GPG support will be the upcoming release (see my other comment). It's actually not as simple as just putting gpg in the smudge and clean filters, since gpg's non-deterministic encryption confuses git. Afraid I can't help with your gpg-agent forwarding. The few times I've needed to do that I had to proxy the GPG agent connection via socat and through ssh port forwarding, which is not very sane (but might be improved with a few well-designed scripts).
- sigil 13y ago
  GPG support will be the upcoming release (see my other comment). Saw that -- awesome. I rolled something similar where gitcrypt.salt and gitcrypt.pass were stored in a gpg-encrypted file. After cloning, you decrypt once with gpg, then un-smudge all the encrypted files. No more gpg after that. How does your solution differ? Is the shared gitcrypt.pass gone entirely? Do I potentially need access to a gpg keyring every time I checkout, diff, log, etc? The few times I've needed to do that I had to proxy the GPG agent connection via socat and through ssh port forwarding, which is not very sane. Yeah, it's too messy for me. My question was, if ssh-agent can be forwarded, why can't gpg-agent be forwarded? Boy was that a rabbit hole. It seems the ssh-agent forwarding protocol is specific enough that it couldn't be used for gpg-agent. Also, while gpg-agent can apparently stand in for ssh-agent when it comes to ssh keys, ssh-agent can't stand in for gpg-agent with gpg keys. Furthermore, I got the sense that the gpg folks don't even want gpg-agent forwarding either -- too insecure for them.
  - agwa 13y ago
    > Saw that -- awesome. I rolled something similar where gitcrypt.salt and gitcrypt.pass were stored in a gpg-encrypted file. After cloning, you decrypt once with gpg, then un-smudge all the encrypted files. No more gpg after that. That's essentially how the GPG feature works. git-crypt doesn't use anything called "gitcrypt.salt" or "gitcrypt.pass" though - you might be confusing git-crypt with another project. (I may very well end up renaming git-crypt - it's a way too generic name.)
    - sigil 13y ago
      That's essentially how the GPG feature works. Cool. I think that's the way to go. If you needed GPG for things beyond the initial checkout, automated git deploys (among other things) would be out of the question. You might be confusing git-crypt with another project. Oh, wow, you're right. I'm using a forked version of something called git-encrypt: https://github.com/shadowhand/git-encrypt https://github.com/shadowhand/git-encrypt This is just a shell script (no compiled code), started about a year before your git-crypt, but interestingly the design is very similar. Both of you are using smudge and clean filters with AES 256.

by sigil 13y ago

agwa 13y ago

git-crypt author here. GPG support will be the upcoming release (see my other comment). It's actually not as simple as just putting gpg in the smudge and clean filters, since gpg's non-deterministic encryption confuses git. Afraid I can't help with your gpg-agent forwarding. The few times I've needed to do that I had to proxy the GPG agent connection via socat and through ssh port forwarding, which is not very sane (but might be improved with a few well-designed scripts).

sigil 13y ago
GPG support will be the upcoming release (see my other comment). Saw that -- awesome. I rolled something similar where gitcrypt.salt and gitcrypt.pass were stored in a gpg-encrypted file. After cloning, you decrypt once with gpg, then un-smudge all the encrypted files. No more gpg after that. How does your solution differ? Is the shared gitcrypt.pass gone entirely? Do I potentially need access to a gpg keyring every time I checkout, diff, log, etc? The few times I've needed to do that I had to proxy the GPG agent connection via socat and through ssh port forwarding, which is not very sane. Yeah, it's too messy for me. My question was, if ssh-agent can be forwarded, why can't gpg-agent be forwarded? Boy was that a rabbit hole. It seems the ssh-agent forwarding protocol is specific enough that it couldn't be used for gpg-agent. Also, while gpg-agent can apparently stand in for ssh-agent when it comes to ssh keys, ssh-agent can't stand in for gpg-agent with gpg keys. Furthermore, I got the sense that the gpg folks don't even want gpg-agent forwarding either -- too insecure for them.
- agwa 13y ago
  > Saw that -- awesome. I rolled something similar where gitcrypt.salt and gitcrypt.pass were stored in a gpg-encrypted file. After cloning, you decrypt once with gpg, then un-smudge all the encrypted files. No more gpg after that. That's essentially how the GPG feature works. git-crypt doesn't use anything called "gitcrypt.salt" or "gitcrypt.pass" though - you might be confusing git-crypt with another project. (I may very well end up renaming git-crypt - it's a way too generic name.)
  - sigil 13y ago
    That's essentially how the GPG feature works. Cool. I think that's the way to go. If you needed GPG for things beyond the initial checkout, automated git deploys (among other things) would be out of the question. You might be confusing git-crypt with another project. Oh, wow, you're right. I'm using a forked version of something called git-encrypt: https://github.com/shadowhand/git-encrypt https://github.com/shadowhand/git-encrypt This is just a shell script (no compiled code), started about a year before your git-crypt, but interestingly the design is very similar. Both of you are using smudge and clean filters with AES 256.