Proposal: remove compatibility for old signing functions
Luke Plant
(shortening the deprecation process).
= Explanation =
In 1.3, various bits of code were updated to use a better system for
signing using the SECRET_KEY. However, for compatibility with existing
data, the old methods were left as fallbacks.
The issue of compatibility with existing *data* is not adequately
handled by our deprecation policies, because the way data is updated can
be very different from the way code is updated.
Once Django 1.3 has been in use on a site for more than the 'lifetime'
of the signed data, then the old signatures are very unlikely to be
used, and in some cases the data will have definitely expired. At this
point, the compatibility code will have served its purpose.
In some cases, the 'lifetime' of the old data is very short, but in
other times it could be longer, depending on some things that are
outside our control. All cases are typically much shorter than a single
Django release cycle though. I am proposing that we drop the fallbacks
for compatibility with the old signing methods in Django 1.4, shortening
the typical deprecation process. These are:
Password reset
- typical lifetime - 3 days. Depends on PASSWORD_RESET_TIMEOUT_DAYS
FormWizard and FormPreview
- typical lifetime - a few minutes
contrib.comments
- typical lifetime - a few minutes
Sessions
- typical lifetime - 2 weeks. Depends on SESSION_COOKIE_AGE
CSRF fallback for Django 1.1
- typical lifetime - a few minutes
= Rationale =
The old code is a source of potential vulnerabilities, and complicates
the code and any security reviews. It is better to get rid of it as soon
as we can.
= Problems =
There is, of course, the case of people who skip Django versions. They
would be left with the upgrade bumps that we were trying to avoid by
having the compatibility code. However, if we follow the deprecation
process at all, it is impossible to eliminate this case - someone could
jump from Django 1.2 to Django 1.5 and get the same issues even if we
followed the normal deprecation process.
To cover this, I would recommend adding something to the release notes
like this e.g.:
<<<
Django 1.3 changed the cryptographic signing mechanisms used in a number
of places in Django. While Django 1.3 kept fallbacks that would accept
the previous methods, these fallbacks are removed in Django 1.4.
So, if you upgrade to Django 1.4 directly from 1.2 or earlier, you may
lose/invalidate certain pieces of data that have been cryptographically
signed using an old method. To avoid this, use Django 1.3 first, for a
period of time, to allow the signed data to expire naturally and to be
replaced with a newer signing mechanism. The affected parts are detailed
below, with 1) the consequences of ignoring this advice and 2) the
amount of time you need to run Django 1.3 for the data to expire.
- sessions
- consequences: session data will be lost, and the user logged out
- time period: defined by SESSION_COOKIE_AGE
- FormWizard and FormPreview
- consequences: the user will see errors with these forms
- time period: the amount of time you expect users
to take filling out the affected forms.
...
>>>
Regards,
Luke
--
"If something is hard, it's not worth doing." (Homer Simpson)
Luke Plant || http://lukeplant.me.uk/
Jacob Kaplan-Moss
> Proposal: remove compatibility fallbacks for short-lifetime signed data
> (shortening the deprecation process).
Sounds perfectly fine to me. Skipping versions is generally a dicey
idea anyway, so recommending a brief stop in 1.3 for people going 1.2
-> 1.4 is a good idea regardless I think.
Jacob
Gabriel Hurley
Paul McMillan
forward. These fallback methods have worried me, and definitely weaken
the security of the improvements.
One idea I had been kicking around was some way to tell Django what
version of these things to expect, and disable the fallbacks for
anything older. Brand new projects don't need the fallbacks. This
might be overly complex, however.
-Paul