I’m happy with that. -- Aymeric.
> On 27 Dec 2016, at 19:49, Tim Graham <timogra...@gmail.com> wrote: > > Thanks Aymeric. How about this documentation addition: > > Uses of the key shouldn't assume that it's text or bytes. Every use should go > through :func:`~django.utils.encoding.force_text` or > :func:`~django.utils.encoding.force_bytes` to convert it to the desired type. > > https://github.com/django/django/pull/7750 > <https://github.com/django/django/pull/7750> > > Adam created https://code.djangoproject.com/ticket/27635 > <https://code.djangoproject.com/ticket/27635> about the "use secrets" idea. > > On Saturday, December 24, 2016 at 4:52:38 PM UTC-5, Aymeric Augustin wrote: > 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-d...@ <>googlegroups.com > <http://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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/50b9dde6-4bab-4f00-b739-df06e90cce3f%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/50b9dde6-4bab-4f00-b739-df06e90cce3f%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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/DEE3DAA8-DF41-4A0F-A9B9-208437F6D604%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
