5 ms·

In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All o

In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All other code is open source. Obviously we don't want to keep api keys etc. in the public repos. [1] https://github.com/sozialhelden/wheelmap https://github.com/sozialhelden/wheelmap

imdsm 11y ago
> we use private repos ... that contain sensitive information (user data). Wait, what?
- Xylakant 11y ago
  email addresses and (account) names of people reporting bugs in private. Some people prefer it that way. Nothing "sensitive sensitive". Sorry for being unclear.
cloverich 11y ago
You shouldn't be keeping api keys or other sensitive information in git at all. And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").
- Xylakant 11y ago
  care to explain why? I need to keep my API keys somewhere so I can roll them out to the machine. Keeping them in git is as good as any storage - what would you propose instead? A shared dropbox account?
  - uxp 11y ago
    The newfangled approach is something like HashiCorp's Vault, which is a dream when you're looking at more than half a dozen systems with similar roles. A different approach that I like to use for single or smaller cluster systems is Ansible's Vault and rolling out config files based on templates per environment. All actual config files are gitignored so I don't have do deal with conflicts on the server if I use a git-pull style deployment, and ansible itself can backup/version whenever they change. Additionally, git does keep that history (as it's supposed to), so if you just delete the key from a private repo as you're trying to make the repo public, it's trivial for someone to walk the commit history looking for historical API keys that might not have been rotated. In order to purge that information from git, you then have to go re-write the commit graph from the point of the key's insertion (with it removed) all the way to the present. It's not impossible to do, it's just a major pain.
    - Xylakant 11y ago
      I'm aware of the implications concerning the history, but sorry, the machine park is two machines. Setting up vault would just be total overkill. The people that have access to that repo change like once every few years. The repo will never go public. Let's keep the solution at least somewhat tailored to the problem.
      - uxp 11y ago
        Hey, I'm not arguing one way or the other. I like using Ansible for configuration in the way I work. I can trust that I can show my best friend and my worst enemy my project and they won't have the capability of making my life hell. Rock on though. Use the simplest solution for the problem at hand. If you're just managing two boxes though, I'd have a hard time coming up with an argument for adding more complexity to the setup to essentially make it unchanged.
        Xylakant 11y ago
        It's all chef-based so we could be using encrypted databags, but as anybody with access to the repo has root on the machines anyways, there's little to gain there as well, especially given the very limited security implications. I'd be more worried that somebody adds his account to the sudoers list that stealing the secret data. But hey, things were that way when I joined and there's better places to spend my time to improve security.
  - neoeldex 11y ago
    All keys are tracked in git's history, so it's a possible attack vector for hackers. You could use https://github.com/sobolevn/git-secret https://github.com/sobolevn/git-secret. But beware, anytime you revoke someone's access, you should regenerate all secrets stored in there. In any case you should always regenerate the keys whenever someone's access is revoked
  - woah 11y ago
    What the hell? Are you defending a decision to keep keys unencrypted in a git repo?
    - Xylakant 11y ago
      yes, indeed I am. I'm all in favor of keeping the tools used to a level where the effort makes sense to protect the value of the goods. I totally could lock up my newrelic api key in a bank safe, double encrypted with two persons 4096 bit GPG keys, but that would be a little overkill, wouldn't it? Do you do that? I'd be moderately annoyed if somebody started pushing false metrics to my NR account, but that's about all the damage they could do with the information in that repo. So what level of effort would you propose?
      - lox 11y ago
        Agreed, we do this as well at some scale. The vast majority of application configuration falls into this category. The advantage of storing them in a git repo (we use a different git repo to the main codebase) is that you can re-use the same access control mechanisms (note that is not the same as giving the same people access to the different repos) and you get strong change history.
    - geofft 11y ago
      It's a perfectly defensible decision. The standard cryptographer's reply at this point would be, what is your threat model? If "A developer could have their GitHub account broken into" or "Someone could break into GitHub deeply enough that they could access private repos" are in your threat model, you shouldn't be using GitHub at all for anything, including code, because it would be straightforward to use that access to subvert your site in other ways. Which is to say, especially for small sites, that's not a useful threat model. If "You might do a git commit to remove them, then push the repo somewhere" is in your threat model, then the answer is just "Don't do that" (or more precisely, "Make sure everyone on the team understands that can't be done without precautions"). The easiest way to don't-do-that is to have them in a separate git repo from your code. But either way, as projects grow, there's going to be stuff in your git history you don't want to be public (like, oh, git commit -m "Implementing this stupid feature because this customer is stupid") because human error happens sometimes. So if you want to publish a previously-private codebase, the only robust approach is to copy all the files into a new non-git repo and make a new commit. And the other part of the cryptographer's reply is, where else are you going to store the secrets and what are its security properties?
- geofft 11y ago
  Git is just a format for storing data with a record of how that data changed. Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs. It's true that if your btrfs disk image becomes public, the data is recoverable, and it's hard to reliably scrub deleted files from btrfs, but that doesn't mean it's the wrong tool for a filesystem (or a repo) that stays entirely internal. Saying that you shouldn't keep it on GitHub is different, and I might be more inclined to agree with that, but it still seems like it's not a 100% rule.
  - Xylakant 11y ago
    > Saying that you shouldn't keep it on GitHub is different I'd be willing to argue about that, but for my newrelic api key, a private github repo is sufficiently safe - even if I'd prefer if nobody starts having his servers report to my account.
  - neoeldex 11y ago
    A git repo is usually shared over multiple machines/developers. So the chance of someone publicating it is larger. As well as the entire history is usually copied everywhere
    - Xylakant 11y ago
      Why would that be a general rule. I track my personal passwords in git (using pass). I'm the only person with access to that repo. I just like to have a history - and the convenient way of moving files around and merging changes.
    - geofft 11y ago
      All of these machines and developers have legitimate access to the secret in question, though. Hence my framing of git as just a file storage format—any other mechanism provides the technical means for any of these machines or developers to publicize it. (And a few other simple mechanisms, like "scp the secret from another machine" or "copy/paste it with your terminal", have an increased risk of doing so by accident. Accidentally making a git repo public is generally unlikely.)
  - 11y ago
pc86 11y ago
Fix your security.
- rdancer 11y ago
  Or... else?
therealmarv 11y ago
never store sensitive data like API keys in a repository. Or you can do that but encrypt it so that nobody which can view your repo (even if it's private) can use that data immediately. It's like storing passwords in plaintext in a DB. Every (DB) admin will tell you: Don't/Never do that. I've recently also have to do with this problems while doing server setup with a private repo. I'm using Ansible and Ansible Vault to encrypt sensitive data and the encryption key itself is only accessible (a password safe) to certain members of our team http://docs.ansible.com/ansible/playbooks_vault.html http://docs.ansible.com/ansible/playbooks_vault.html
- Xylakant 11y ago
  see, the whole repo is accessible to the members of the team that are allowed to see the secret - basically the two folks that have root on the machine anyways. There's very limited use in encrypting the repo. There are no SSL keys or any secrets that would require tight security. It's basically our newrelic and some other api keys for reporting services. Even if that repo would be breached you could only start sending fake data to those services. I'm more concerned about someone hacking the machine than someone hacking github to access the repo and retrieve the newrelic key from there.
  - therealmarv 11y ago
    ok, agree. That is not that critical.
thomasahle 11y ago
And you share the passwords with enough volunteers that per users pricing becomes a problem?
- Xylakant 11y ago
  I don't handle the account in that case, so I can't even say if it's free or not. I was just replying to the implied question "why would a nonprofit org with an OS project need private repos?"
- deleted 11y ago
  [deleted]

imdsm 11y ago

> we use private repos ... that contain sensitive information (user data). Wait, what?

Xylakant 11y ago
email addresses and (account) names of people reporting bugs in private. Some people prefer it that way. Nothing "sensitive sensitive". Sorry for being unclear.

cloverich 11y ago

You shouldn't be keeping api keys or other sensitive information in git at all. And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").

Xylakant 11y ago
care to explain why? I need to keep my API keys somewhere so I can roll them out to the machine. Keeping them in git is as good as any storage - what would you propose instead? A shared dropbox account?
- uxp 11y ago
  The newfangled approach is something like HashiCorp's Vault, which is a dream when you're looking at more than half a dozen systems with similar roles. A different approach that I like to use for single or smaller cluster systems is Ansible's Vault and rolling out config files based on templates per environment. All actual config files are gitignored so I don't have do deal with conflicts on the server if I use a git-pull style deployment, and ansible itself can backup/version whenever they change. Additionally, git does keep that history (as it's supposed to), so if you just delete the key from a private repo as you're trying to make the repo public, it's trivial for someone to walk the commit history looking for historical API keys that might not have been rotated. In order to purge that information from git, you then have to go re-write the commit graph from the point of the key's insertion (with it removed) all the way to the present. It's not impossible to do, it's just a major pain.
  - Xylakant 11y ago
    I'm aware of the implications concerning the history, but sorry, the machine park is two machines. Setting up vault would just be total overkill. The people that have access to that repo change like once every few years. The repo will never go public. Let's keep the solution at least somewhat tailored to the problem.
    - uxp 11y ago
      Hey, I'm not arguing one way or the other. I like using Ansible for configuration in the way I work. I can trust that I can show my best friend and my worst enemy my project and they won't have the capability of making my life hell. Rock on though. Use the simplest solution for the problem at hand. If you're just managing two boxes though, I'd have a hard time coming up with an argument for adding more complexity to the setup to essentially make it unchanged.
      - Xylakant 11y ago
        It's all chef-based so we could be using encrypted databags, but as anybody with access to the repo has root on the machines anyways, there's little to gain there as well, especially given the very limited security implications. I'd be more worried that somebody adds his account to the sudoers list that stealing the secret data. But hey, things were that way when I joined and there's better places to spend my time to improve security.
- neoeldex 11y ago
  All keys are tracked in git's history, so it's a possible attack vector for hackers. You could use https://github.com/sobolevn/git-secret https://github.com/sobolevn/git-secret. But beware, anytime you revoke someone's access, you should regenerate all secrets stored in there. In any case you should always regenerate the keys whenever someone's access is revoked
- woah 11y ago
  What the hell? Are you defending a decision to keep keys unencrypted in a git repo?
  - Xylakant 11y ago
    yes, indeed I am. I'm all in favor of keeping the tools used to a level where the effort makes sense to protect the value of the goods. I totally could lock up my newrelic api key in a bank safe, double encrypted with two persons 4096 bit GPG keys, but that would be a little overkill, wouldn't it? Do you do that? I'd be moderately annoyed if somebody started pushing false metrics to my NR account, but that's about all the damage they could do with the information in that repo. So what level of effort would you propose?
    - lox 11y ago
      Agreed, we do this as well at some scale. The vast majority of application configuration falls into this category. The advantage of storing them in a git repo (we use a different git repo to the main codebase) is that you can re-use the same access control mechanisms (note that is not the same as giving the same people access to the different repos) and you get strong change history.
  - geofft 11y ago
    It's a perfectly defensible decision. The standard cryptographer's reply at this point would be, what is your threat model? If "A developer could have their GitHub account broken into" or "Someone could break into GitHub deeply enough that they could access private repos" are in your threat model, you shouldn't be using GitHub at all for anything, including code, because it would be straightforward to use that access to subvert your site in other ways. Which is to say, especially for small sites, that's not a useful threat model. If "You might do a git commit to remove them, then push the repo somewhere" is in your threat model, then the answer is just "Don't do that" (or more precisely, "Make sure everyone on the team understands that can't be done without precautions"). The easiest way to don't-do-that is to have them in a separate git repo from your code. But either way, as projects grow, there's going to be stuff in your git history you don't want to be public (like, oh, git commit -m "Implementing this stupid feature because this customer is stupid") because human error happens sometimes. So if you want to publish a previously-private codebase, the only robust approach is to copy all the files into a new non-git repo and make a new commit. And the other part of the cryptographer's reply is, where else are you going to store the secrets and what are its security properties?
geofft 11y ago
Git is just a format for storing data with a record of how that data changed. Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs. It's true that if your btrfs disk image becomes public, the data is recoverable, and it's hard to reliably scrub deleted files from btrfs, but that doesn't mean it's the wrong tool for a filesystem (or a repo) that stays entirely internal. Saying that you shouldn't keep it on GitHub is different, and I might be more inclined to agree with that, but it still seems like it's not a 100% rule.
- Xylakant 11y ago
  > Saying that you shouldn't keep it on GitHub is different I'd be willing to argue about that, but for my newrelic api key, a private github repo is sufficiently safe - even if I'd prefer if nobody starts having his servers report to my account.
- neoeldex 11y ago
  A git repo is usually shared over multiple machines/developers. So the chance of someone publicating it is larger. As well as the entire history is usually copied everywhere
  - Xylakant 11y ago
    Why would that be a general rule. I track my personal passwords in git (using pass). I'm the only person with access to that repo. I just like to have a history - and the convenient way of moving files around and merging changes.
  - geofft 11y ago
    All of these machines and developers have legitimate access to the secret in question, though. Hence my framing of git as just a file storage format—any other mechanism provides the technical means for any of these machines or developers to publicize it. (And a few other simple mechanisms, like "scp the secret from another machine" or "copy/paste it with your terminal", have an increased risk of doing so by accident. Accidentally making a git repo public is generally unlikely.)
- 11y ago

pc86 11y ago

Fix your security.

rdancer 11y ago
Or... else?

therealmarv 11y ago

never store sensitive data like API keys in a repository. Or you can do that but encrypt it so that nobody which can view your repo (even if it's private) can use that data immediately. It's like storing passwords in plaintext in a DB. Every (DB) admin will tell you: Don't/Never do that. I've recently also have to do with this problems while doing server setup with a private repo. I'm using Ansible and Ansible Vault to encrypt sensitive data and the encryption key itself is only accessible (a password safe) to certain members of our team http://docs.ansible.com/ansible/playbooks_vault.html http://docs.ansible.com/ansible/playbooks_vault.html

Xylakant 11y ago
see, the whole repo is accessible to the members of the team that are allowed to see the secret - basically the two folks that have root on the machine anyways. There's very limited use in encrypting the repo. There are no SSL keys or any secrets that would require tight security. It's basically our newrelic and some other api keys for reporting services. Even if that repo would be breached you could only start sending fake data to those services. I'm more concerned about someone hacking the machine than someone hacking github to access the repo and retrieve the newrelic key from there.
- therealmarv 11y ago
  ok, agree. That is not that critical.

thomasahle 11y ago

And you share the passwords with enough volunteers that per users pricing becomes a problem?

Xylakant 11y ago
I don't handle the account in that case, so I can't even say if it's free or not. I was just replying to the implied question "why would a nonprofit org with an OS project need private repos?"
deleted 11y ago
[deleted]