Closed dlapiduz closed 8 years ago
Is this necessary? I actually would prefer not to phrase the advice of keeping secrets/etc out of source control as an "exception" to open source, since API keys aren't source code. If this was phrased as general advice to teams elsewhere in the practice.md
document, that would be more ideal. Most ideally, it would be accompanied by 18F's team practices for preventing the leak of API keys, which I think are not finalized yet.
Would a compromise be saying something like "no sensitive information should be included in public repositories (or repositories at all?), e.g. passwords, PII, etc"? No strong feelings about it living in policy vs practices.
@konklone I know they are not "source code" but that distinction might escape someone who is reading this so I think we need to call it out explicitly.
This is a policy and security control on GitHub itself and was already promulgated via the Handbook. In fact, I have a PR up to update said provision to the new incident response process.
What we already had in the Handbook should be sufficient.
Yeah, I just think this is a slippery slope for our open source policy. And as I just noted in a comment, the language would need more consensus-building among the team, especially if it's going to be in the policy text. (IP addresses and PII should not be treated the same way as API keys and other secrets.)
While our practices regarding API keys and other secrets are worth documenting somewhere, they're more appropriate for "how 18F is authorized to use GitHub" than "18F's open source policy".
Happy to take more PRs to the implementation guidance (i.e. how 18F is authorized to use GitHub)
(Adding context) In the process of reviewing our policies with our auditors we found that there is no place where we say that password or secrets should be kept out of open source. I can commit an admin key without violating any 18F policy.
I think its not a bad idea to change that.