git-secret - store your private data inside a repository

There’s a known problem in server configuration and deploying, when you have to store your private data such as: database passwords, application secret-keys, OAuth secret keys and so on, outside of the git repository. Even if this repository is private, it is a security risk to just publish them into the world wide web. What are the drawbacks of storing them separately?

These files are not version controlled. Filenames change, locations change, passwords change from time to time, some new information appears, other is removed. And you can not tell for sure which version of the configuration file was used with each commit. When building the automated deployment system there will be one extra step: download and place these secret-configuration files where they need to be. So you have to maintain an extra secure server, where everything is stored. How does git-secret solve these problems?

git-secret encrypts files and stores them inside the git repository, so you will have all the changes for every commit. git-secret doesn’t require any other deploy operations rather than git secret reveal, so it will automatically decrypt all the required files. What is git-secret?

git-secret is a bash tool to store your private data inside a git repo. How’s that? Basically, it just encrypts, using gpg, the tracked files with the public keys of all the users that you trust. So everyone of them can decrypt these files using only their personal secret key. Why deal with all this private-public keys stuff? Well, to make it easier for everyone to manage access rights. There are no passwords that change. When someone is out - just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore.

Find out more: https://sobolevn.github.io/git-secret/

Have you seen the much older pwstore tool? https://github.com/formorer/pwstore

It does have some notable features missing from git-secret and similar
tools to this day.
- Whitelist of trusted keys to detect addition of unexpected keys.
- Specify what users/groups have access to any given file (via a header
  in each file, which implies that the file must be plaintext).

I've wondered if storing metadata about the objects in notes might
improve matters: 
- a clearsigned block with verifiable readable data (eg who in a team
  can access)
- an encrypted block with the inner key (nice side effect that this
  separates versioning of the wrapped inner key from the versioning of
  the object).

This also a nice property that when you revoke/remove an outer (user) key, can know implicitly the old secrets they had access to (which should probably be rotated, as you don't know if they have a copy of them outside of the system).

Yes, I'm aware of other system's like Hashicorp's Vault, but do appreciate the simplicity of git-secret, pass [1], pwstore [2] and other simpler tools.

[1] https://www.passwordstore.org/
[2] https://github.com/formorer/pwstore
    It's at least as old as the Git history indicates, possibly
	older, I don't know if the Git history included a full conversion of
	SVN history.

Robin, thank you for interest.

I have not seen 'pwstore' before, but I don't like the idea to store headers inside the file. As it might break things. But I love the idea of groups and access rights. It is a direction I would like to follow. Also I like your suggestion about the key's white-list. That's a feature I have already planed for the future releases.

I guess 'pass' was made for a single user. But 'git-secret' was made for multiple people. So you can invite someone to share your encrypted files and easily remove them. Also, I have noticed that 'pass' stores the encrypted files in the separate repository. Well, that's an arguable way to go. It has some benefits like: code-repository and pass-repository may have different access rights, different people involved. But there's a lack in consistency when you have two separate repositories.

2016-03-14 2:52 GMT+03:00 Robin H. Johnson <robbat2@gentoo.org>:

On Mon, Mar 14, 2016 at 10:22:43AM +0300, Никита Соболев wrote:

Maybe using notes for the ACL metadata would work out, not sure.

Yes, 'pass' did start for a single user; and added per-folder access groups later. It's also that it aims to be a simple secret storage tool (no random blobs), with an optional Git backing (simply making the directory versioned), rather than secret-storage-for-any-git-repo.

I included pass also because it has some nice UX (IMO).