3 ms·
That's why I try to never put any testing or development keys in repositories. From those keys sitting there it just takes one act of negligence for the keys to
by ThePhysicist 4y ago
That's why I try to never put any testing or development keys in repositories. From those keys sitting there it just takes one act of negligence for the keys to make it into a production environment. It's really frustrating that most people don't care about this at all. Even people forking my own projects would not listen when I told them to please just generate the keys dynamically (for which I included all necessary functionality in the software itself, easily accessible in CI and from the CLI via a simple make command), and instead just put dev keys smack in the repository [1]. And mind you those were some really "security minded" people from the CCC.
1: https://github.com/impfen/apps-inoeg/blob/main/tests/fixtures/keys/002_admin.json https://github.com/impfen/apps-inoeg/blob/main/tests/fixture...
- time0ut 4y agoThis. I always generate my keys or certs or whatever as part of my dev workflow scripts, configure the local environment to read these, and then gitignore the resulting files. This way it just works for the rest of team and the mechanisms are plainly visible in the repo. There are many ways to do this, but one that often fits what I am doing is to use terraform’s TLS provider [0]. Terraform has become pretty ubiquitous for me. I am probably already using it to power other parts of my dev environment setup and teardown. Adding in a call to a little module that spits out a dynamic CA and certs signed by it is really easy. [0] https://registry.terraform.io/providers/hashicorp/tls/latest/docs https://registry.terraform.io/providers/hashicorp/tls/latest...