Conversation
There was a problem hiding this comment.
Thanks, @JosephTLucas! I feel we should also leave a link to Scientific Python's SPEC 6 – Keys to the Castle here, as a part of it also addresses a similar topic. What do you think?
|
|
||
| ## Best Practices for Secret Handling | ||
|
|
||
| 1. **Never store passwords or tokens directly in your repository.** Use something like GitHub Secrets to manage your secrets during CI/CD. |
There was a problem hiding this comment.
| 1. **Never store passwords or tokens directly in your repository.** Use something like GitHub Secrets to manage your secrets during CI/CD. | |
| 1. **Never store passwords or tokens directly in your repository.** Use secrets on GitHub or similar tooling to manage your secrets during CI/CD. |
"GitHub Secrets" makes me feel as if it's an official product/service offered by GitHub to manage secrets, and it doesn't show up as such on search engines, so it could be misleading – I'm curious to hear your thoughts.
There was a problem hiding this comment.
Good point, I can clarify with "secrets in GitHub Actions"
bestpractices/content/passwords.md
Outdated
| Even with a password manager, mistakes can happen. You or a contributor might accidentally commit a password, API key, or other credentials to the repository. Fortunately, tools like [trufflehog](https://github.com/trufflesecurity/trufflehog) can help detect these secrets before they make their way into production or public repositories. | ||
|
|
There was a problem hiding this comment.
I think we should also mention that GitHub also has its secret scanning service, which is available for free for public repositories: https://docs.github.com/en/code-security/secret-scanning/enabling-secret-scanning-features (and paid for private repositories).
The last time I checked, it used to be enabled by default – I'm a bit surprised that's no longer the case (or I'm misremembering).
Great idea. Do you have some specific context you want to add? If so, feel free to add it directly. Great review by the way, thank you! I appreciate it. |
Co-authored-by: Agriya Khetarpal <[email protected]>
Co-authored-by: Agriya Khetarpal <[email protected]>
Co-authored-by: Agriya Khetarpal <[email protected]>
Co-authored-by: Agriya Khetarpal <[email protected]>
Co-authored-by: Agriya Khetarpal <[email protected]>
Co-authored-by: Agriya Khetarpal <[email protected]>
Co-authored-by: Agriya Khetarpal <[email protected]>
Co-authored-by: Agriya Khetarpal <[email protected]>
Thank you, the pleasure is all mine! I'll have to think about any additional context to include here, as that SPEC was geared more towards general security practice(s) of managing project-specific resources and not password management in specific. Maybe just a link to it in the conclusion would be alright as a resource for extra reading? I'll push a commit to add it. |
|
Reminder for me: will add list of examples of accounts for password manager. For example 1Password has an option for various "vaults", such as "social-media". This permits specific maintainers to access specific vaults. |
Closes #8