10 ms·

> 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

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

andrewstuart2 8y ago
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.
- dharmab 8y ago
  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.
  - freedomben 8y ago
    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.
deleted 8y ago
[deleted]
mooreds 8y ago
Would you put secrets into a circleci environment variable? https://circleci.com/docs/2.0/env-vars/ 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.
- drdaeman 8y ago
  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 https://github.com/mozilla/sops (you can use that with GnuPG as well)
  - iancarroll 8y ago
    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?
    - drdaeman 8y ago
      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.
      - jwhitlark 8y ago
        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.
rbosinger 8y ago
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?
- habitue 8y ago
  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)
- snowwrestler 8y ago
  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-from-a-repository/ 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.
gammateam 8y ago
Just store them as environment variables on computational instance that runs the code Use non-production ones on non-production servers
mavsman 8y ago
> 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.
- deleted 8y ago
  [deleted]
- rk06 8y ago
  That's why he wrote it. To claim no-responsibilty, when it happens
sschueller 8y ago
I would expect better from the creator of Vue.js
- sopooneo 8y ago
  Honestly, yes. Some brilliant people cleary have blind spots for certain basic web dev best practices.
ibudiallo 8y ago
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.
menzoic 8y ago
Not only GitHub staff but any attacker that gains priviledged access to GitHub servers

andrewstuart2 8y ago

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.

dharmab 8y ago
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.
- freedomben 8y ago
  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.

deleted 8y ago

[deleted]

mooreds 8y ago

Would you put secrets into a circleci environment variable? https://circleci.com/docs/2.0/env-vars/ 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.

drdaeman 8y ago
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 https://github.com/mozilla/sops (you can use that with GnuPG as well)
- iancarroll 8y ago
  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?
  - drdaeman 8y ago
    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.
    - jwhitlark 8y ago
      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.

rbosinger 8y ago

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?

habitue 8y ago
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)
snowwrestler 8y ago
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-from-a-repository/ 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.

gammateam 8y ago

Just store them as environment variables on computational instance that runs the code Use non-production ones on non-production servers

mavsman 8y ago

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

deleted 8y ago
[deleted]
rk06 8y ago
That's why he wrote it. To claim no-responsibilty, when it happens

sschueller 8y ago

I would expect better from the creator of Vue.js

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

ibudiallo 8y ago

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.

menzoic 8y ago

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