In the past, I've worked on a couple of django projects where we violated the:
# SECURITY WARNING: keep the secret key used in production secret!"
advice because on day one, somebody didn't know what we they were doing and never fixed it. Looking around at a collection of django projects (by various developers), I see that's often the case. SECRET_KEY, oauth keys, aws keys, etc all end up in settings.py files. And show up in github, etc.
This is not terribly surprising. I expect most people just sit down with
the tutorial, follow the first example:
$ django-admin startproject mysite
and instantly have a working, but insecure, setup.
So, why not have startproject start people off on the right foot? Build a settings.py file and a secret_settings.py file. Put the SECRET_KEY in secrets.py. Have settings.py do "from secret_settings import SECRET_KEY". Make secret_settings.py mode 0400 by default (or whatever that translates to on windows). Print out a message telling people to exclude secret_settings.py from version control.
As people add more secrets, they have a low-effort path to continuing to do something reasonable. A more sophisticated user can tear that out and replace it with their own secrets infrastructure. But, at least we will have started newbies off with something reasonable.
I see this has
been discussed before, but I disagree with a lot of the opinions in that thread. This wouldn't be forcing developers to do it any specific way. It just provides a default that's better than the current default. Expecting that newbies to follow best practices just because they're documented somewhere is irrational, as can be seen by perusing github.