+1 to what Aymeric wrote. I was just drafting an email with a similar argument about how it's hard to manage pure bytes in config management systems that write to env vars, that's why ascii strings are so useful. They're also easy to copy/paste and verify when adding them to your config management.
On 22 December 2016 at 22:15, Aymeric Augustin < aymeric.augustin.2...@polytechnique.org> wrote: > 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. > -- Adam -- 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/CAMyDDM0Y3XruMz-knHLm5bRZn3X%2BZPPr1fC6ohh%2B91YhCfD%3Dew%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
