Hacker News new | comments | show | ask | jobs | submit login

After 4 months of usage, I don't recommend using git-crypt.

The main issue is that because transforms between the encrypted and decrypted state are transparent, it's very easy to commit files in clear that should have been encrypted. The .gitattributes patterns are not always obvious. Also .gitattibutes doesn't support encrypting the whole repo because it's lacking the negating parameter that allow you to encrypt everything except the .gitattribute file.

The second issue is that a lot of times I ended up having my repo in an inconsistent state. Some times, especially during rebases, something would go wrong and encrypted files would get marked as dirty even if they haven't changed. Running `git checkout` on these files would not work to put them back in a consistent state. I would have to remove the git-crypt config in .git/config and reset the repo to fix the issue. Some times the file didn't decrypt properly, although thing might have been an issue between the combination of git and git-crypt versions.

So in short, git-crypt is an awesome idea but I think is at the wrong level of abstraction. It relies on feature that haven't really been designed for security.

EDIT: To be a bit more constructive: the first issue could be mitigated by adding a `git-crypt check <path>` that tells you if a file is encrypted or not behind the scene.




Thanks for your feedback. It's true that there are still edge cases where the repo can get in an inconsistent state. This is the biggest issue I need to address before the 1.0 release. I should be able to provide commands that will fix up the repo if this happens. And thanks for pointing me in the direction of rebases - I clearly haven't done enough testing with them.

As for security, .gitattributes actually does have negation capability (see the article for an example) so you can encrypt the whole repo by default and explicitly whitelist files to not be encrypted. But I must emphasize that if you are encrypting most or all of the files in your repo, git-crypt is not the best tool because as you point out, git filters haven't really been designed for this. Where git-crypt really shines is where most of your repo is public, but you have a few files (perhaps private keys named *.key, or a file with API credentials) which you need to encrypt. I do like your suggestion of a command to check if a file is being encrypted, and plan to implement that.


I had to go back to the man pages. I think I got stuck at the "Unlike .gitignore, negative patterns are forbidden." and missed that you could unset attributes instead :)

In the process I also found `git check-attr` that goes 90% of the way of the `git crypt check` idea. Eg: `git check-attr -a -- path/to/file` will output git-crypt if the file is encrypted. A `git crypt ls` that lists all the encrypted files could be useful too to give more visibility.


> In the process I also found `git check-attr` that goes 90% of the way of the `git crypt check` idea. Eg: `git check-attr -a -- path/to/file` will output git-crypt if the file is encrypted. A `git crypt ls` that lists all the encrypted files could be useful too to give more visibility.

That's extremely useful - thanks for passing on that info!


> Where git-crypt really shines is where most of your repo is public, but you have a few files (perhaps private keys named *.key, or a file with API credentials) which you need to encrypt.

Awesome, this is just my use case. I had been not sure if this was actually the use case you were focusing on -- I'd suggest maybe including that exact above sentence in the README, so potential users can understand what you are intending the tool for.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: