Live data from Hacker News

Git-secret – store private data in a Git repo

coderwall.com

21–30 of 74 posts

Re: Git-secret – store private data in a Git repo

#21
post #19
post #18

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

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

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.

Re: Git-secret – store private data in a Git repo

#22

> 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.

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.

Re: Git-secret – store private data in a Git repo

#23

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...

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

Re: Git-secret – store private data in a Git repo

#25
post #21
post #19

Earlier quoted context omitted.

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

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.

Exactly!.

The page says "When someone is out - just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore." but doesn't talk about rotating the secrets.

This practice seems unnecessary to me.

Re: Git-secret – store private data in a Git repo

#26
post #21
post #19

Earlier quoted context omitted.

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

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.

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.

Re: Git-secret – store private data in a Git repo

#27
post #21
post #19

Earlier quoted context omitted.

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

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.

Second that, if there are many people having access to the repository and you maintain repo's history, rotating encryption keys and secrets won't save you, unless you also delete the whole history and do some major updates to the files. Someone can answer to that that he can put the ciphertests in a separate repository and limit repo's access to only deployment server/user, but that completely invalidates the goal.

Re: Git-secret – store private data in a Git repo

#28
post #8

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 fil…

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/

Re: Git-secret – store private data in a Git repo

#29
post #18

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

Agree, also check out credstash[0], a very good and secure solution if you are running on AWS. Credstash is an small utility that encrypt with KMS and store the ciphertext of the datakey and secret on Dynamodb.

I configure my application roles to be able to decrypt with the master key and I restrict what ciphertext they can read from Dynamodb.

[0] https://github.com/fugue/credstash

Post reply on HN