Yes, I believe git-crypt is secure for that use case (as long as you keep your git-crypt key secure, of course). Although I'm not a professional cryptographer, I've taken Coursera's crypto course, have read Cryptography Engineering, and keep myself informed of the various pitfalls and attacks on crypto.

On the theory side, git-crypt uses AES in CTR mode with a nonce derived from the HMAC of the file. This is provably secure against an attack model called deterministic chosen-plaintext attack. In this regard, git-crypt is more secure than many similar projects (such as git-encrypt), which use AES in ECB mode or CBC mode with a fixed IV. These systems leak information and are not secure against deterministic chosen-plaintext attacks.

On the implementation side, git-crypt uses OpenSSL's crypto functions and the crypto code is extremely simple - pretty much a textbook example of how to properly do AES in CTR mode.

If anyone's curious, here's the code where AES-CTR is implemented: https://github.com/AGWA/git-crypt/blob/master/crypto.cpp#L76

And here is where it calculates the nonce (and also checks to make sure the counter value won't be overflowed): https://github.com/AGWA/git-crypt/blob/master/commands.cpp#L...

yea been wondering about this as well.. basically usage in general.

i've been thinking its a cheap-skate way to get private repos for free on github... XD but really the ideal use case would be to be able to keep passwords & sensitive info in the repo but have it make it to production without having to manually re-config.

i'm assuming if you put the key on your webserver it would be able to do this? also assuming you are on a service where you can actually access the filesystem outside your repo

(o and the reason this relates to your comment being.... would be nice to have it pass through github on way to prod. then it could be a nice dev+github+AWS kindof deploy process)

Yep, my use case is basically the same as yours.

I'm not just trying to score a free private repo, I actually want to share my app code with others open source who would like to view it -- even though the app itself is customized for our context, I don't mind letting people see it.

If you deploy your app with capistrano or similar automation, there are various ways to handle deploy. Not neccesarily any need to access any file systems, if you are deploying to heroku for instance, you might just need your deploy tool to set heroku config/env variables.

Anyhow, as far as whether git-crypt is really designed for this use case, I'm encouraged by a comment from the author here in this thread: "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." Where most of your repo is actually public, yep, but just a file or two with credentials etc that need to be encrypted, yep! Okay, sweet.