Hacker News Reader

Comment by snowwrestler | Hacker News Reader

> Credentials are stored in lib/credentials.json. This is checked into the repo, so USE A PRIVATE REPO.

It's called a "private" repo, not a "secure" repo.

The point of a private repo is to give you control over your collaborators. It is not to provide information security. To my knowledge, Github makes no special promises about the security of private repos. The data is not encrypted on disk at Github, and Github staff can access the content of your repo.

I WOULD NOT UPLOAD SECRETS INTO A GITHUB PRIVATE REPO.

View on HN

This should not be a problem anymore. My pull request has just been merged.

There is a sample credential file to be renamed to credentials.json, this file is now in gitignore.

Would you put secrets into a circleci environment variable? https://circleci.com/docs/2.0/env-vars/

That might be an improvement over checking in the json file, as I suspect (from a very brief look) that that is why the json file is checked in.

If I'd decide to keep the secrets in the repo, I would have them encrypted with e.g. GnuPG and put a key in the CI's environment variables.

    # Something in lines of this...
    # TODO: Make sure the keyrings are on tmpfs, too.
    # Something like export GNUPGHOME="/run/gnupg" && mkdir -p "$GNUPGHOME"
    gpg2 -v --import <(echo "$GPG_PRIVATE_KEY")
    gpg2 --decrypt --output /run/secrets/credentials.json lib/credentials.json.gpg
    ln -s /run/secrets/credentials.json lib/credentials.json

For this I have to trust the CI, of course... And given that CI jobs run in isolated environments but on a shared hosts, there could be a way for malicious party to access the data. IIRC, there were some exploits that break out of Docker.

If you host in the cloud that offers a KMS (AWS, GCP, Azure), a slightly advanced alternative is SOPS: https://github.com/mozilla/sops (you can use that with GnuPG as well)

I don’t get what this accomplishes. You can either put the secrets in the environment variables, or put all the information required to decrypt the environment variables in the environment variables.

What does the latter give you?

Idea is, if someone gets access to your CI environment but not the repo - they don't have the data to decrypt. E.g. if your CircleCI password is leaked, but GitHub is safe. In my experience, most CI websites don't allow to browse the source code.

That's not ideal - IIRC, CircleCI in particular has a feature to run the build with SSH, so a sufficiently aware attacker still has a way to get the decrypted data. Still, an extra obstacle. Just that security's not binary.

Also, this way you can manage the secrets in your repo. No need to log in to CI and use their web UI to edit the passwords. I think that's convenient.

Sops is a better idea, because you can't extract keys from the KMS.

This problem is one reason why it's important to separate CI from CD. If you do that, then circleci would only have what's needed to test and package it, and the CD can handle the rest, although ideally you'll have a third piece for secrets.

Or at least unencrypted secrets. If you've properly encrypted the data, then it really shouldn't matter where it ends up as long as you keep the key appropriately private.

As long as the encryption isn't broken for the lifetime of the secret. This is enough of a sufficiently hard condition to guarantee that it should not be a general recommended practice.

You should be rotating your secrets regularly. As long as you do that and use an industry standard encryption implementation (never roll your own!) you should be gtg. Everyone differs on how often to rotate secrets. some people say every 10 minutes (projects like vault make this easier) some say 6 months, some say a year.

I've heard this before from people but I can help but think, "companies are paying GitHub to store code which in itself is often very valuable IP that needs to be protected". Are we sure GitHub doesn't have any promises to the protection of private repos? Obviously anything could happen and it's best to encrypt secrets and such... but if it's true that GitHub is not very serious about protecting the contents of private repos seems off to me. Any links to anything regarding their stance on this?

There's a big difference between proprietary code and secrets. If you get my proprietary code you will be able to understand and copy how my application works, but (if I've coded it well) you won't be able to compromise a running instance. This is why open-source software is not necessarily less secure than closed-source software.

But if you get my secrets, you can most likely own that instance.

And I think it's worth pointing out that companies who are serious about the trade secrecy of their code tend to host their own repos. I don't think you'll find critical source code from Microsoft, Google, Facebook, Apple, etc. sitting in private repos on Github.com.

I've been using Github private repos at work since 2013. As I said, I've not seen anything from Github that says that private repos are secure enough to upload secrets. For example, this document does not distinguish between public and private repos:

https://help.github.com/articles/removing-sensitive-data-fro...

I use private repos to interact with contractors. Just because I grant a contractor access to collaborate on a private repo, that doesn't mean I want them to have my api keys, passwords, etc.

I use private repos because I want a cheap and easy way to host git repos, but I don't want to bother with the public. I don't want to create the false impression that I'm open to pull requests or forking my code.

The features of github means the data can't just be left encrypted all the time. No matter what, github employees are going to have access to your code. If you absolutely require security github enterprise is the on-prem way to remove the risk of a rogue github employee (to just the risk of your own rogue employees)

I would expect better from the creator of Vue.js

Honestly, yes. Some brilliant people cleary have blind spots for certain basic web dev best practices.

Just store them as environment variables on computational instance that runs the code

Use non-production ones on non-production servers

> I will not take responsibility for any potential leak of sensitive information.

That's not how it works. You know at least one person will put their key in a public repo by accident. Wouldn't this give anyone complete access to their bank account? Seems like a pretty scary thing to check creds into the repo.

That's why he wrote it. To claim no-responsibilty, when it happens

Not only GitHub staff but any attacker that gains priviledged access to GitHub servers

Reply on news.ycombinator.com