4 ms·

I agree with mahouse and of course are some of these password legit. But this is nothing new, don't store sensitive data in git. Everyone know you can search th

by ins0 11y ago

I agree with mahouse and of course are some of these password legit. But this is nothing new, don't store sensitive data in git. Everyone know you can search this stuff on GitHub and if we look back - Google was a nice password search engine too (and still today)

reustle 11y ago
Don't store sensitive data in git, or don't store sensitive data on public github repos?
- archimedespi 11y ago
  Don't even store sensitive data in git, it can be a bad idea: http://www.jamiembrown.com/blog/one-in-every-600-websites-has-git-exposed/ http://www.jamiembrown.com/blog/one-in-every-600-websites-ha... Store credentials in environment variables.
  - jessaustin 11y ago
    That link is talking about a problem with e.g. .htaccess and basic directory permissions, not a problem using git per se. But yeah, put that stuff in envars.
  - Huggernaut 11y ago
    How would you go about making a repeatable, automated deployment if you don't store configuration information in source control to load into the environment variables?
    - aaronbasssett 11y ago
      Depends on what you're using for your deployments, for example if you were using Puppet you might use something like https://github.com/TomPoulton/hiera-eyaml https://github.com/TomPoulton/hiera-eyaml
      - Huggernaut 11y ago
        Sorry, how does this prevent you requiring configuration in source control, or are you just suggesting that those credentials should be encrypted?
    - archimedespi 11y ago
      Consul and Vault go a long way to achieving that. https://consul.io/ https://consul.io/ https://vault.io https://vault.io
      - Huggernaut 11y ago
        Doesn't this just push the problem up (down?) a level in the hierarchy? I mean, you still need to deploy these and configure them with the information the rest of your deployment requires right?
- jessaustin 11y ago
  If there's any question, I think the rule has to be the former. There are standard, auditable ways to keep sensitive data out of git: .gitignore, environmental vars, etc. Once it's in git, any attempts to keep it out of a public repo will probably be manual and ad hoc. If the organization is "closed" by default, i.e. it only rarely releases code to the public, this may not matter as much.

by ins0 11y ago

reustle 11y ago

Don't store sensitive data in git, or don't store sensitive data on public github repos?

archimedespi 11y ago
Don't even store sensitive data in git, it can be a bad idea: http://www.jamiembrown.com/blog/one-in-every-600-websites-has-git-exposed/ http://www.jamiembrown.com/blog/one-in-every-600-websites-ha... Store credentials in environment variables.
- jessaustin 11y ago
  That link is talking about a problem with e.g. .htaccess and basic directory permissions, not a problem using git per se. But yeah, put that stuff in envars.
- Huggernaut 11y ago
  How would you go about making a repeatable, automated deployment if you don't store configuration information in source control to load into the environment variables?
  - aaronbasssett 11y ago
    Depends on what you're using for your deployments, for example if you were using Puppet you might use something like https://github.com/TomPoulton/hiera-eyaml https://github.com/TomPoulton/hiera-eyaml
    - Huggernaut 11y ago
      Sorry, how does this prevent you requiring configuration in source control, or are you just suggesting that those credentials should be encrypted?
  - archimedespi 11y ago
    Consul and Vault go a long way to achieving that. https://consul.io/ https://consul.io/ https://vault.io https://vault.io
    - Huggernaut 11y ago
      Doesn't this just push the problem up (down?) a level in the hierarchy? I mean, you still need to deploy these and configure them with the information the rest of your deployment requires right?
jessaustin 11y ago
If there's any question, I think the rule has to be the former. There are standard, auditable ways to keep sensitive data out of git: .gitignore, environmental vars, etc. Once it's in git, any attempts to keep it out of a public repo will probably be manual and ad hoc. If the organization is "closed" by default, i.e. it only rarely releases code to the public, this may not matter as much.