I’m wondering how people distrubute private keys and passwords to other developers with source control, particularly when the code is open source. For example with the calendar @sil emails me when we add a new key for google, eventbrite or something, but this doesn’t seem like a good solution. John Resig suggests encrypting keys in the source. Anyone do this or have alternative solution?
I assume by private keys you’re talking about API secrets and things like that rather than key pairs for logging in to servers?
Generally it’s best to store those sorts of things in environment variables on the application server itself, rather than in source control. You could encrypt the keys in source, I know ansible has a thing called Vault which lets you do this.
This is what I’ve always assumed was the case, and works great for people using server-side technology - but how do people building using client-side technologies do it?
… which is what we do. But how do those keys get to the server? (you are correct; these are generally API keys and secrets.) @rythie has access to the server and I don’t, but I have the keys because I’m the one who signed up for them. So what I do is email him the keys and he puts them in the server envars, but as noted this is not ideal. So what’s better?
When I worked in Big Electricity servers, they were getting into distributed key trees but it’s a bit of a nightmare to administer. When I moved into information risk management I met people who were stripping out a lot of encryption after locking themselves out of their own server farms and the backups requiring the keys they’d lost. Multiple cheap removable hard drives with no physical identification that a criminal would recognise, kept in lofts are a popular option… but rats.
Standard ‘threat, risk, control’ analysis then reassess to decide if the solution is more dangerous than the problem.
At my last employer we used a Keepass file in source control for e.g. shared passwords, API keys. The Keypass file was protected by a pass phrase. The pass phrase was also in source control, but encrypted/signed w each developer’s GPG key e.g.
gpg --sign --encrypt -r email@example.com -r ... keepass-passphrase.txt.gpg
keepass-passphrase.txt was listed in
.gitignore. This was also used directly for other secrets e.g.
example.org.crt.key.gpg, with a smaller set of GPG identities.
We also tried git-crypt for a while. It was problematic for us at the time, because we were actually using git-svn. It’s probably fine in a native git environment.
Eventually Ansible Vault replaced some of the direct GPG usage. IIRC the Vault pass phrase was then encrypted with GPG and committed.
git-crypt looks rather like the right approach here, I think!
ansible vault has worked well for me in the past
if the threat model justified it I’d guess a GPG based solution would be harder to crack, but more complex to work with
If you’re using client-side technologies, your API key should be a client key. i.e., it should not have the ability to do anything destructive. Lots of services with a JS library now have ‘secret’ API keys which are only for deleting/updating things and public keys for reading data.
If you’re emailing keys to eachother, try using keybase.io. It’s basically a nice UI wrapper around GPG with verification built in. Means you can send secret data to each other safely.
Nah, the concern here is not the security of me emailing keys to @rythie; it’s that we shouldn’t have to email keys around at all, and instead I should just commit them to the repository but in a way that means that others can’t see them. Hence, git-crypt seems useful.
The last app I was working on had a config file on an S3 bucket which we’d periodically update (and tell everyone else to then update theirs). This was mildly brittle as this file wasn’t version controlled (although its template was), but it worked for us.
I have mixed feelings about git-crypt. Although in this instance it sounds like it would be a good fit for you, I have a bad feeling about storing anything secret in source control. But I suppose if it’s a private repo and your GPG keys are long enough, then it shouldn’t really be a problem