#19980: Signer broken when SECRET_KEY contains non-ASCII bytes
-------------------------------------+-------------------------------------
Reporter: nvie | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: 1.5
Severity: Normal | Resolution:
Keywords: signer | Triage Stage: Design
Has patch: 0 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by anonymous):
I would argue that, given that this is used in cryptographic contexts, the
key should be bytes, not a string. At the lowest level, all crypto happens
on bytes anyway, and with strings you always rely on an encoding. Even
though we can assume utf-8 fairly reasonably, this still is an assumption,
and basically only used to convert the unicode string to a byte string.
Why then, let us not pass in the bytes explicitly, independent of an
encoding?
Also, this patch would make it compatible with the Django<1.5 behaviour.
Even more so, this would make it similar to other web frameworks. For
example, in Flask, the `SECRET_KEY` value is recommended to be generated
completely random, using `os.urandom()`. Thus, a byte string.
If consensus is around using a unicode string nonetheless, this should be
explicitly documented at the very least, and maybe even type-checked.
--
Ticket URL: <https://code.djangoproject.com/ticket/19980#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
