{"thread":{"id":"41682","subject":"git-secret - store your private data inside a repository","startedAt":"2016-03-13T14:11:30Z","lastAt":"2016-03-14T18:04:20Z","messageCount":4,"participants":["Никита Соболев","Robin H. Johnson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"280683","messageId":"CAO_bL1xQ0C+HYdZQVvyHx3ByPaaJTgpQYhY7h9f76eQXHKZ_SQ@mail.gmail.com","threadId":"41682","inReplyTo":null,"subject":"git-secret - store your private data inside a repository","fromName":"Никита Соболев","fromEmail":"n.a.sobolev@gmail.com","sentAt":"2016-03-13T14:11:30Z","receivedAt":"2016-03-13T14:11:30Z","isPatch":false,"sender":{"key":"n.a.sobolev@gmail.com","avatar":null},"body":"There’s a known problem in server configuration and deploying, when\nyou have to store your private data such as: database passwords,\napplication secret-keys, OAuth secret keys and so on, outside of the\ngit repository. Even if this repository is private, it is a security\nrisk to just publish them into the world wide web. What are the\ndrawbacks of storing them separately?\n\nThese files are not version controlled. Filenames change, locations\nchange, passwords change from time to time, some new information\nappears, other is removed. And you can not tell for sure which version\nof the configuration file was used with each commit.\nWhen building the automated deployment system there will be one extra\nstep: download and place these secret-configuration files where they\nneed to be. So you have to maintain an extra secure server, where\neverything is stored.\nHow does git-secret solve these problems?\n\ngit-secret encrypts files and stores them inside the git repository,\nso you will have all the changes for every commit.\ngit-secret doesn’t require any other deploy operations rather than git\nsecret reveal, so it will automatically decrypt all the required\nfiles.\nWhat is git-secret?\n\ngit-secret is a bash tool to store your private data inside a git\nrepo. How’s that? Basically, it just encrypts, using gpg, the tracked\nfiles with the public keys of all the users that you trust. So\neveryone of them can decrypt these files using only their personal\nsecret key. Why deal with all this private-public keys stuff? Well, to\nmake it easier for everyone to manage access rights. There are no\npasswords that change. When someone is out - just delete his public\nkey, reencrypt the files, and he won’t be able to decrypt secrets\nanymore.\n\nFind out more: https://sobolevn.github.io/git-secret/\n"},{"id":"280692","messageId":"robbat2-20160313T211905-684299027Z@orbis-terrarum.net","threadId":"41682","inReplyTo":"CAO_bL1xQ0C+HYdZQVvyHx3ByPaaJTgpQYhY7h9f76eQXHKZ_SQ@mail.gmail.com","subject":"Re: git-secret - store your private data inside a repository","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2016-03-13T23:52:50Z","receivedAt":"2016-03-13T23:52:50Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"Have you seen the much older pwstore tool?\nhttps://github.com/formorer/pwstore\n\nIt does have some notable features missing from git-secret and similar\ntools to this day.\n- Whitelist of trusted keys to detect addition of unexpected keys.\n- Specify what users/groups have access to any given file (via a header\n  in each file, which implies that the file must be plaintext).\n\nI've wondered if storing metadata about the objects in notes might\nimprove matters: \n- a clearsigned block with verifiable readable data (eg who in a team\n  can access)\n- an encrypted block with the inner key (nice side effect that this\n  separates versioning of the wrapped inner key from the versioning of\n  the object).\n\nThis also a nice property that when you revoke/remove an outer (user)\nkey, can know implicitly the old secrets they had access to (which\nshould probably be rotated, as you don't know if they have a copy of\nthem outside of the system).\n\nYes, I'm aware of other system's like Hashicorp's Vault, but do\nappreciate the simplicity of git-secret, pass [1], pwstore [2] and other\nsimpler tools.\n\n[1] https://www.passwordstore.org/\n[2] https://github.com/formorer/pwstore\n    It's at least as old as the Git history indicates, possibly\n\tolder, I don't know if the Git history included a full conversion of\n\tSVN history.\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Developer, Infrastructure Lead, Foundation Trustee\nE-Mail     : robbat2@gentoo.org\nGnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85\n"},{"id":"280702","messageId":"CAO_bL1y8tp5+NKdPqpwqJvX2xWY6Wg1oZbnRTKAVjKrg94b3BA@mail.gmail.com","threadId":"41682","inReplyTo":"robbat2-20160313T211905-684299027Z@orbis-terrarum.net","subject":"Re: git-secret - store your private data inside a repository","fromName":"Никита Соболев","fromEmail":"n.a.sobolev@gmail.com","sentAt":"2016-03-14T07:22:43Z","receivedAt":"2016-03-14T07:22:43Z","isPatch":false,"sender":{"key":"n.a.sobolev@gmail.com","avatar":null},"body":"Robin, thank you for interest.\n\nI have not seen 'pwstore' before, but I don't like the idea to store\nheaders inside the file. As it might break things. But I love the idea\nof groups and access rights. It is a direction I would like to follow.\nAlso I like your suggestion about the key's white-list. That's a\nfeature I have already planed for the future releases.\n\nI guess 'pass' was made for a single user. But 'git-secret' was made\nfor multiple people. So you can invite someone to share your encrypted\nfiles and easily remove them. Also, I have noticed that 'pass' stores\nthe encrypted files in the separate repository. Well, that's an\narguable way to go. It has some benefits like: code-repository and\npass-repository may have different access rights, different people\ninvolved. But there's a lack in consistency when you have two separate\nrepositories.\n\n2016-03-14 2:52 GMT+03:00 Robin H. Johnson <robbat2@gentoo.org>:\n> Have you seen the much older pwstore tool?\n> https://github.com/formorer/pwstore\n>\n> It does have some notable features missing from git-secret and similar\n> tools to this day.\n> - Whitelist of trusted keys to detect addition of unexpected keys.\n> - Specify what users/groups have access to any given file (via a header\n>   in each file, which implies that the file must be plaintext).\n>\n> I've wondered if storing metadata about the objects in notes might\n> improve matters:\n> - a clearsigned block with verifiable readable data (eg who in a team\n>   can access)\n> - an encrypted block with the inner key (nice side effect that this\n>   separates versioning of the wrapped inner key from the versioning of\n>   the object).\n>\n> This also a nice property that when you revoke/remove an outer (user)\n> key, can know implicitly the old secrets they had access to (which\n> should probably be rotated, as you don't know if they have a copy of\n> them outside of the system).\n>\n> Yes, I'm aware of other system's like Hashicorp's Vault, but do\n> appreciate the simplicity of git-secret, pass [1], pwstore [2] and other\n> simpler tools.\n>\n> [1] https://www.passwordstore.org/\n> [2] https://github.com/formorer/pwstore\n>     It's at least as old as the Git history indicates, possibly\n>         older, I don't know if the Git history included a full conversion of\n>         SVN history.\n>\n> --\n> Robin Hugh Johnson\n> Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee\n> E-Mail     : robbat2@gentoo.org\n> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85\n"},{"id":"280723","messageId":"robbat2-20160314T172243-113693201Z@orbis-terrarum.net","threadId":"41682","inReplyTo":"CAO_bL1y8tp5+NKdPqpwqJvX2xWY6Wg1oZbnRTKAVjKrg94b3BA@mail.gmail.com","subject":"Re: git-secret - store your private data inside a repository","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2016-03-14T18:04:20Z","receivedAt":"2016-03-14T18:04:20Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Mon, Mar 14, 2016 at 10:22:43AM +0300, Никита Соболев wrote:\n> Robin, thank you for interest.\n> \n> I have not seen 'pwstore' before, but I don't like the idea to store\n> headers inside the file. As it might break things. But I love the idea\n> of groups and access rights. It is a direction I would like to follow.\n> Also I like your suggestion about the key's white-list. That's a\n> feature I have already planed for the future releases.\nMaybe using notes for the ACL metadata would work out, not sure.\n\n> I guess 'pass' was made for a single user. But 'git-secret' was made\n> for multiple people. So you can invite someone to share your encrypted\n> files and easily remove them. Also, I have noticed that 'pass' stores\n> the encrypted files in the separate repository. Well, that's an\n> arguable way to go. It has some benefits like: code-repository and\n> pass-repository may have different access rights, different people\n> involved. But there's a lack in consistency when you have two separate\n> repositories.\nYes, 'pass' did start for a single user; and added per-folder access\ngroups later. It's also that it aims to be a simple secret storage tool\n(no random blobs), with an optional Git backing (simply making the\ndirectory versioned), rather than secret-storage-for-any-git-repo.\n\nI included pass also because it has some nice UX (IMO).\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Developer, Infrastructure Lead, Foundation Trustee\nE-Mail     : robbat2@gentoo.org\nGnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85\n"}]}