Hi @danielquinn@lemmy.ca , author here.
Thanks for taking the time for such an in-depth comment 👍 . I’m gonna try to answer point by point.
On different configurations and settings
Although I strongly agree with your take (from your recent blog post) that if ENVIRONMENT == "prod": should never happen, I’m really surprised about this:
Your configuration & settings should be identical between environments
I think there’s a misunderstanding here. Here’s how I see it:
- A “setting” is a constant your application needs at runtime to make a decision about its behavior
- A “configuration” is a way of running your application, with some “settings” preset and some “settings” required from the “environment”
- An “environment” is a place where your application runs under a certain “configuration” that you’ve chosen, and this “environment” provides the values for the “settings” your chosen “configuration” requires
This way of thinking enables you to have multiple environments running the same configuration with different values for some settings.
As for:
how exactly to do expect to find & fix problems that only occur in production?
From my experience, 99% of the time, problems that only occur in production are all about data and edge cases, not about configuration. And I’ve learned to avoid making the whole structure of my application constrained by 1% of the cases.
On secrets-in-repo
To be honest I have no experience with secrets-in-repo, and I am seeking feedback, but:
secrets in the repo (…) requires a code change (+CI run, +deploy) to change any of the values.
How changing of .env file is considered a code change? Of course it triggers a deploy, but it should not trigger a CI run, as the application behavior did not change, only some envvar in some environment. Changing an .env file is exactly as changing an envvar through your cloud provider console, with the only difference that the envvars are yours, which is pretty important to me.
instead of just one environment to configure, you have potentially dozens: production, staging, testing, and one for every developer who’s ever worked there
This has nothing to do with storing secrets in the repo, but everything to do with how many environments you have. I think many teams like to have at least one staging environment, don’t you think?
how they might have stored the keys in plain text on their machine
I don’t see any difference with the infamous ~/.aws/credentials file that we all have on our work computer, that allows an attacker to fetch all secrets from all environments with the right AWS API calls. Yes, a developer who gets their laptop stolen and who did not encrypt the disk represents a huge risk to their company.
When Steve gets fired, how many files do you have to decrypt, edit, and re-encrypt to rotate the secrets?
Just the ones that are non-development, typically production and staging. Steve did not have the keys to other files, this is the whole point of the strategy I chose of having 2 keys (one individual, one shared). To be honest, even for not-so-small teams, this would not be a long task. Also, when I join a team or when I build a team, I don’t expect people getting fired too often 😅
All that might be acceptable if the benefits were high, but they aren’t.
I guess that’s subjective then. Because IMO, being independent from cloud providers when it comes to handling my applications secrets is a great benefit. Maybe I’m wrong on the risks/benefits ratio between the independence benefits and the security risks, but nothing in your comment convinces me that storing secrets in the Git repo is less safe than storing them in a vault that I access with a key that I have on my laptop.
On licensing
I’m sorry but unless you point me to legal sources, I think you’re wrong about what the GPLv3 means ; I’ve studied this topic carefully before choosing that licence because it’s my first open source piece of code.
No, using a GPLv3 web project template as base of a new web project doesn’t make the larger project a “derivative work” that must also be published under GPLv3, for two reasons:
- What makes the GPLv3 license “viral” is when a program “links” to a GPLv3 licensed library ; using a project template does not “link” (in a software sense) the newly created project to the template (i.e. there will be no
from mytemplate import somethingin your Django project, thus your project won’t be considered as “derivative work”) - It’s the “distribution” of the covered software (modified or unmodified) that triggers the obligation of publishing the source under GPLv3 ; remote execution (e.g. a web application) is not “distribution”, this is why AGPL exists. Examples of Django reusable apps published under GPLv3 exist (e.g. jazzband/django-invitations ; imagine if everybody using this had to release their own website under GPLv3?)
In contrast, what would be considered as “derivative work” is someone enriching my Django project template in order to sell a standardized Django experience as part of their consultancy. They would have to release under GPLv3 the changes (fixes and new features) they would make to my template.
I like your suggestion to look at Creative Commons licenses though, maybe it would make sense, thanks.
Thank you for the clarifications about how the GPL license applies, and what the consequences are.
If I’m following you correctly:
So in the case of my Django project template:
Thanks for the discussion, I’ve learned a lot!