If you are non profit and open source do you really need private repos?
Honest question... why?
I totally understand the mindset of "gotta go all secret squirrel to protect our profits" but if your org isn't in it for the profits there's not much to protect?
I have seen examples of people performing very naughty acts like private repos to hold plain text passwords, plain text cloud service keys, plain text corporate credit card numbers for expense payments, etc.
Private repos are a good way to review code for things like plaintext passwords and service keys before it's in production. If a developer commits something with a key, and code review goes "Oh, you shouldn't have put that there," and it was public, now you have to rekey. Private repos allow that code review step to take place.
(They're also pretty useful for legacy code where eliminating all the private keys is difficult and not an immediate priority, and for the rare but existent cases where including private keys in source is the right engineering tradeoff for new development.)
There's also no way to disable pull requests and other outside comments on your code, other than making a private repo. Having it private is a simple way to avoid inviting the public to have opinions all over your repo.
We had two main competitors in our space, and while the ultimate goal for everyone including our competitors was to do a common good, we were competing for a limited pool of donation dollars.
Because of that, sharing any intellectual property that made us better at what we did (i.e., raise more money, hire more staff, fund more initiatives) could result in a competitor using that same IP to put us out of business.
I get that in the big picture, it's not the way things should be done, but in the small picture, you're usually talking about individuals with their own agendas.
- You're experimenting - You don't want comments from the peanut gallery while things are in progress - It is not for external use, specific to an institution or project, or otherwise nobody else will care - It deals with something sensitive - You've made an agreement with someone else that requires it - etc. etc. etc.
People seem to have weird notions about nonprofits. Your tax structure doesn't change the fact that you operate in a world of other human beings.
However for a bigger enterprise they require more functionality here is a comparison of the differences between the Community and Enterprise Editions.
https://about.gitlab.com/features/#compare
Several pricing options for EE but essentially the base cost is $39 /year per user.
I don't see the problem here. Your employees will have access to your private repos, and the volunteers will not (thus you won't be paying for their seats).
Wait, what?
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.
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?
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.
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.
Best practice is to avoid storing secrets in plaintext, or sharing secrets between users/roles. Yours isn't an argument in favour of git, it is an argument against btrfs.
(I don't have any problem with storing passwords in that way, I'm just pointing out why it's not the best practice.)
How do you store them, then? If they're encrypted with a password, how do you store that secret?
I'm pretty sure best practice is in fact to store things like SSL private keys, cookie HMAC secrets (e.g. Django's SECRET_KEY), and so forth on local disk unencrypted, protected by only filesystem permissions (and the host OS as a whole protected with standard means). In fact I'm not even sure it's possible to store OpenSSH private keys unencrypted.
> or sharing secrets between users/roles.
There's only one role here: the application that has an API key. There are multiple developers of that application, and possibly multiple instances of that application, but it's a single role.
OpenSSH server private keys, on the other hand - I don't think that makes a whole lot of sense. Unless you have a threat model that forces you to encrypt the entire server disk, but then adding private key encryption on top of that doesn't make much sense either.
It's just one role, but multiple users.
Also, does this rule out hosting on clouds that don't offer vTPM support? (Are there any that do?)
Chrome OS uses TPM heavily[1], and iOS has the Security Enclave. The standard TPM API is PKCS#11, so any hardware that speaks it can be used with any software that speaks it.
Problem with TPM is that the whole hardware and software stack needs to be secure, which in practice means it needs to be designed top-down with awareness of the TPM, and audited. The secrets must not be cached, written to file system, kept in memory, leaked over network. There are implementations such as Trousers[2], but it's more or less just a proof of concept; it may provide additional security, but most likely you're just using a very complex lock, and leaving the key under the mat.
[1] https://www.chromium.org/developers/design-documents/tpm-usa... [2] http://trousers.sourceforge.net/man/tpmtoken_setpasswd.1.htm...
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
I'm more concerned about someone hacking the machine than someone hacking github to access the repo and retrieve the newrelic key from there.
"Being a nonprofit" doesn't mean "developing open source software".