Hello, In my opinion, recommending or enforcing that SECRET_KEY contain random bytes would be a backwards incompatible change, bring no practical advantage, and make it more difficult to manage SECRET_KEY securely. I’m -1 on that.
startproject always generated an ASCII str on Python 2 and Python 3. While I don’t think startproject should be a consideration going forwards — if anything, it should be nuked from orbit, because if SECRET_KEY is stored in the code repository and copied on all developer’s laptops, it might as well be “hunter2” — startproject is still the best reference of what SECRET_KEY should look like. Everyone I knows mimics the format when they implement a more decent way to set SECRET_KEY, for example: export SECRET_KEY=… # generated with pwgen -s 50 SECRET_KEY = os.environ[‘SECRET_KEY’] (Of course a configuration management system is a better option but that’s a luxury many small or medium projets can’t afford.) Since very few people use bytes, especially on Python 3, recommending or enforcing bytes will be a de facto backwards incompatibility. Apps that use SECRET_KEY.encode() to obtain bytes and worked just find will crash when the type of SECRET_KEY changes to bytes. Forcing every Django project to change `SECRET_KEY = os.environ[‘SECRET_KEY’]` to `SECRET_KEY = os.environ[‘SECRET_KEY’].encode()` doesn’t sound particularly useful to me. Recommending random bytes — the point of the proposal as far as I understand — is likely cause security issues. For example, how many developers will accidentally end up with a null byte in a SECREY_KEY they initialize from an environment variable, making it much shorter as intended? If the docs started recommending generating SECRET_KEY with random bytes, that would certainly qualify as a security vulnerability. I get that SECRET_KEY is often used in cryptographic contexts where things will eventually be converted to bytes and hashed. However, a careful audit of its use in the current version Django shows that a text key (unicode / str) will work everywhere while a bytes key will crash in some places. (This is a bug and it should be fixed.) The reasons brought in support of the change look weak to me: - “I think it's fair to assume devs using the SECRET_KEY know it must be used as bytes.” — well that doesn't include me or any Django dev I ever talked to about this topic - “The output from a subprocess.check_output() call is in bytes” — this ignores the universal_newlines argument; really you have a choice, depending on your use case - “Django accepts the SECRET_KEY as bytes” — more accurately, that works in most places, but not everywhere Some comments also suggest a incomplete understanding of entropy. <secret> and base64.b64encode(<secret>) have the same entropy — and the latter can be used as is, it doesn’t need decoding. Talking of “bytes that aren’t fully random” doesn’t make sense in this context. If Django needs N bytes of entropy, then it should hash the SECRET_KEY (and perhaps a salt) with a hash function whose output has length N. In short, what matters is the total entropy of the secret key, as explained by Malcolm. So — is the theoretical purity of optimizing the encoding of SECRET_KEY and the economy of 20 bytes worth throwing all these new problems at developers? I don’t think so. Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5F15C6CB-FA9B-466A-A909-2D2DBB43E24A%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
