Hello Andres, We both seem to agree with the status quo — supporting both text and bytes.
On 24 Dec 2016, at 00:36, 'Andres Mejia' via Django developers (Contributions to Django itself) <django-developers@googlegroups.com> wrote: > On 12/22/2016 05:15 PM, Aymeric Augustin wrote: >> export SECRET_KEY=… # generated with pwgen -s 50 > What do you think is ultimately being used in the pwgen program? I'm going to > guess, at least on POSIX systems, it is /dev/urandom or /dev/random, both of > which return random bytes. I understand this, but it doesn’t change my argument. I’m saying that the format of SECRET_KEY doesn’t matter, as long as it contain enough entropy, since it will be injected in hashing algorithms designed to extract the entropy. I think we can agree on this. We have different preferences for that format. You like keeping the original raw binary data SECRET_KEY. I find it more convenient to convert it to an ASCII-safe format, for example with pwgen. I really think this boils down to taste. I don’t think we can conclusively determine that one approach is superior to the other. I think my technique is more beginner friendly; while not applicable to you, it’s a concern for Django in general. The only cost of supporting both options is that every use must go either through force_text or force_bytes to convert to a known type. >> - “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 > (..) Oops, I misunderstood “used as bytes” to mean “defined as bytes”. Sorry. I withdraw this. And since I’ve been waving my hands about the types Django expects in a previous email, here’s the full audit. Below, text means unicode on Python 2 and str on Python 3. ASCII-safe bytes means bytes containing only ASCII-characters, so they can be used transparently as if they were text on Python 2, because it will call decode() implicitly. - django/conf/global_settings.py Sets the default to an empty text string (note the unicode_literals import at the top for Python 2). - django/conf/settings.py-tpl Sets the generated value to ASCII-safe bytes on Python 2 and text on Python 3 (no unicode_literals there). - django/core/signing.py: Calls force_bytes to support bytes and text in get_cookie_signer. - django/utils/crypto.py: Calls force_bytes to support bytes and text in salted_hmac. Assumes SECRET_KEY contains text in the `if not using_sysrandom` branch of `get_random_string`. This is the bug I hinted to in a previous email. It must have appeared when adding the unicode_literals import to that file. No one complained since June 2012. It only affects people setting their SECRET_KEY to bytes on Python 3 or ASCII-unsafe bytes on Python 2 on Unix-like systems that don’t provide /dev/urandom. This sounds uncommon. While we’re there, we should use https://docs.python.org/3/library/secrets.html#module-secrets <https://docs.python.org/3/library/secrets.html#module-secrets> on Python >= 3.6. 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/EE6BF997-FDEB-404B-AC9A-7D1C16ABF482%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
