
Git-secret – store private data in a Git repo - bitsweet
https://coderwall.com/p/e-azzg/store-your-private-data-inside-a-git-repository
======
jedberg
This project scares me because it helps foster a bad practice -- keeping
secrets in a repo. You really shouldn't be keeping secrets in the repo.

You should be using a secrets service that is designed for such a purpose,
like Hashicorp's Vault[0], so that you never have to keep a secret in the
code.

[0] [https://github.com/hashicorp/vault](https://github.com/hashicorp/vault)

~~~
Kinnard
Perhaps it's an alternative practice/behavior rather than a "bad" practice?

~~~
tptacek
It's a bad practice, because git makes keys practically irrevocable. It's not
enough to rotate encryption keys, because the old ciphertexts are in the git
history; you have to rotate the underlying secrets as well (people don't do
this and shouldn't have to).

Don't store encrypted secrets in git if you can avoid it.

~~~
siliconc0w
The problem is you need some repository to store this information and it's
incredibly helpful to store the configuration along with the code.

If someone has access to a shared secret and then shouldn't you should assume
the secret is now compromised and rotate it. Rotating the keys doesn't solve
this problem.

~~~
tptacek
No. If that were the case, there would be no purpose to rotating keys. The
problem is that despite rotating keys, your old crypto keys have permanent
access to secrets, because the old _ciphertexts_ are by default retained in
the git history.

It's a bad idea to store secrets in any form in your source code repository.

~~~
startling
I think what grandparent and others are saying is that you also revoke the
secrets contained in the ciphertext, e.g. if it's an AWS key you would revoke
that AWS key on AWS's side as well as encrypting new secrets with a different
encryption key.

Obviously this is a huge hassle and isn't easily done with all kinds of
secrets (which is what I think you're getting at?). But it's also often
necessary.

------
aeontech
Nice work!

I've been using [https://github.com/AGWA/git-
crypt](https://github.com/AGWA/git-crypt) until now, always good to have more
alternatives.

Can you tell us what is different about your approach with this project?

~~~
ioquatix
I've started using git-crypt for deploying configuration. It keeps things
simple and ensures that keys are not in plain text on bit-bucket which is
basically good enough right now.

------
Confiks
I've been using ansible-vault to solve this problem in our infrastructure
repository. A symmetric vault key is encrypted using gpg, and Ansible's
vault_password_file is set to to an executable shell script containing `gpg
--batch --use-agent --descrypt vault_key.gpg`.

Very specific to Ansible, but works fine. It's a shame only files containing
variables (we're using group_vars) can be encrypted, and not arbitrary files
or templates.

~~~
rgj
More things about Ansible vault that are a shame:

\- no file encryption, only YML

\- no separate values, only entire file

\- OMG it's s...l...o...w...

\- password based instead of certs

\- only one password

\- password cannot even stored in an env var

More: [http://jpmens.net/2014/02/22/my-thoughts-on-ansible-s-
vault/](http://jpmens.net/2014/02/22/my-thoughts-on-ansible-s-vault/)

~~~
RRRA
A good trick I found was to have a file with your values assigned as
vault_something and then in the clear version have the variable assigned as:
something: "{{ vault_something }}"

But yeah, the "only one password" is the biggest pain for me...

------
cs702
Another tool worth looking into is git-gpg, which allows you to store
encrypted git repositories on third-party / potentially insecure servers, but
unlike this tool it stores all changes to source files as compressible textual
deltas (a key reason for using git in the first place). The repository is
encrypted remotely but the local version has no encrypted blobs inside.

[https://github.com/rustyio/git-gpg](https://github.com/rustyio/git-gpg)

Other benefits include architectural simplicity and low footprint: it consists
of a single Python script that you add to your executable path.

------
TheHippo
Similar project, that I personally use quite often:
[https://github.com/StackExchange/blackbox](https://github.com/StackExchange/blackbox)

~~~
YesThatTom2
I'm glad that blackbox is gaining in popularity. Future directions for the
project are listed here:
[https://github.com/StackExchange/blackbox/blob/master/Versio...](https://github.com/StackExchange/blackbox/blob/master/Version2-Ideas.md)

------
y0ghur7_xxx
This should really work with ssh public/private keys¹. Public keys are
probably already on the box the git server runs on, and users already have
them generated to access git - no need to generate separate gpg keys.

If you have a github account the script could also get the pubkey directly
from the github api...

¹[http://superuser.com/questions/576506/how-to-use-ssh-rsa-
pub...](http://superuser.com/questions/576506/how-to-use-ssh-rsa-public-key-
to-encrypt-a-text)

~~~
bencord0
SSH keys aren't really used for encryption. Typical ssh uses some kind of DH
construct, with the ssh keypairs just used for authentication.

However, stackexchange is the right place to go if you want to use asymmetric
secret storage in git.

[https://github.com/stackexchange/blackbox](https://github.com/stackexchange/blackbox)

~~~
talaketu
See [https://www.netmeister.org/blog/sharing-secrets-using-ssh-
ke...](https://www.netmeister.org/blog/sharing-secrets-using-ssh-keys.html)
and [https://github.com/jschauma/jass](https://github.com/jschauma/jass)

------
adamkochanowicz
I used to put .gpg files in my repos that stored sensitive information like
database passwords and such.

I don't do that anymore. The main problem as I saw it was that you basically
liberate your security to an environment you can't monitor or send rejections
to (if someone downloads your gpg file). Compare this to an ssh server which
affords both those abilities.

------
perlgeek
> When someone is out - just delete his public key, reencrypt the files, and
> he won’t be able to decrypt secrets anymore.

But they still can encrypt old versions stored in git, no? Do you change all
secrets when somebody leaves the team/company? I guess that'd be best
practice, but I have no idea how often that's done out there.

~~~
stouset
Yes, they can still decrypt old versions.

Storing secret keys, API keys, etc. in your git repo is a terrible idea and an
antipattern any way you slice it. Keep your secrets out of version control.

The quoted advice is extremely bad. If someone who has access to a secret of
any importance leaves your team, the _only_ acceptable response is to rotate
the secret.

------
gechr
A word of warning to those considering using this. While I completely
understand why people might want to encrypt/decrypt files within their public
Git repositories, doing so doesn't come for free.

As Junio C Hamano explains more eloquently and in greater depth here[1], one
thing to bear in mind with this (and similar) tools is that they store the
managed files as binary blobs, regardless of their original format, meaning
that a change to the source file of even a single bit will result in an
entirely different _uncompressed_ blob being stored, rather than a
compressible textual delta.

[1] [http://article.gmane.org/gmane.comp.version-
control.git/1132...](http://article.gmane.org/gmane.comp.version-
control.git/113221)

~~~
apetresc
While technically true, the type of data this extension is meant for (small
configuration snippets containing sensitive credentials) are both small and
rarely-changing. A couple extra bytes in the index won't be a very big deal.

------
nsaje
At Zemanta, we developed py-secretcrypt[0] and go-secretcrypt[1] for keeping
secrets encrypted with Amazon KMS (Key Management Service) in our repos. They
are then decrypted on the fly by the application.

Access control is managed through AWS KMS key policies, with EC2 instances
running the applications having permissions to decrypt the secrets.

Blog post about this will follow soon.

[0] [https://github.com/Zemanta/py-secretcrypt](https://github.com/Zemanta/py-
secretcrypt)

[1] [https://github.com/Zemanta/go-secretcrypt](https://github.com/Zemanta/go-
secretcrypt)

------
tshadwell
See also:
[https://github.com/StackExchange/blackbox](https://github.com/StackExchange/blackbox)
"blackbox by StackExchange"

------
ericfrederich
Hmm... adding access controls to Git? I'm not sure how I feel about this. I
like how Git is low level and stays away from all of that stuff leaving it up
to wrappers like GitLab, GitHub, Gerrit, etc.

When you remove someone from the list of users does it have to go and re-write
history? Isn't that a big no-no in Git?

~~~
apetresc
I have nothing to do with this project, but I think the answer to your
question is no - you don't have to re-write history. If the removed party had
access to previous revisions signed with his key, they're already
"compromised" as far as security is concerned. Whether or not you rewrite
history, he already has it.

The re-encryption they're referring to is presumably just to protect future
revisions (since you would ideally rotate all keys they had access to, git-
secret or not, and publish new ones right away).

------
passive
If you need to do this, I would recommend looking at Transcrypt:
[https://github.com/elasticdog/transcrypt](https://github.com/elasticdog/transcrypt)

------
beefsack
If all you have is a hammer, everything looks like a nail.

------
fibo
I am using keybase.io to store soft secrets like the coveralls.io token. Let
me share my simple use case: [http://g14n.info/2014/07/my-keybase-
experience/](http://g14n.info/2014/07/my-keybase-experience/)

------
marcosnils
Some cross platform tool that we've developed for our company which has some
nice features

[https://github.com/franela/vault](https://github.com/franela/vault)

------
miles_matthias
I've been using
[https://github.com/ahoward/sekrets](https://github.com/ahoward/sekrets) in
private repos for years. Great tool.

I definitely agree this should be used with heavy caution and only in private
repos.

~~~
stouset
This should not even be used in private repos unless the only person who will
ever access the repo is you.

------
seletskiy
Recently, I've wrote simple tool for storing secrets like passwords in public
Git repos using AES cypher:
[https://github.com/seletskiy/carcosa/](https://github.com/seletskiy/carcosa/)

