Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Cleaned up 1.5.4/1.4.8 release notes

  • Loading branch information...
commit 8d29005524b141da8ff4d9b9bc4d858d43bb7154 1 parent aae5a96
@timgraham timgraham authored
View
6 docs/howto/error-reporting.txt
@@ -117,6 +117,8 @@ Filtering error reports
Filtering sensitive information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. currentmodule:: django.views.decorators.debug
+
Error reports are really helpful for debugging errors, so it is generally
useful to record as much relevant information about those errors as possible.
For example, by default Django records the `full traceback`_ for the
@@ -240,11 +242,13 @@ attribute::
request.exception_reporter_filter = CustomExceptionReporterFilter()
...
+.. currentmodule:: django.views.debug
+
Your custom filter class needs to inherit from
:class:`django.views.debug.SafeExceptionReporterFilter` and may override the
following methods:
-.. class:: django.views.debug.SafeExceptionReporterFilter
+.. class:: SafeExceptionReporterFilter
.. method:: SafeExceptionReporterFilter.is_active(self, request)
View
7 docs/releases/1.4-alpha-1.txt
@@ -337,9 +337,10 @@ docs </ref/contrib/csrf>` for more information.
Error report filtering
~~~~~~~~~~~~~~~~~~~~~~
-Two new function decorators, :func:`sensitive_variables` and
-:func:`sensitive_post_parameters`, were added to allow designating the
-local variables and POST parameters which may contain sensitive
+We added two function decorators,
+:func:`~django.views.decorators.debug.sensitive_variables` and
+:func:`~django.views.decorators.debug.sensitive_post_parameters`, to allow
+designating the local variables and POST parameters that may contain sensitive
information and should be filtered out of error reports.
All POST parameters are now systematically filtered out of error reports for
View
7 docs/releases/1.4-beta-1.txt
@@ -375,9 +375,10 @@ docs </ref/contrib/csrf>` for more information.
Error report filtering
~~~~~~~~~~~~~~~~~~~~~~
-Two new function decorators, :func:`sensitive_variables` and
-:func:`sensitive_post_parameters`, were added to allow designating the
-local variables and POST parameters which may contain sensitive
+We added two function decorators,
+:func:`~django.views.decorators.debug.sensitive_variables` and
+:func:`~django.views.decorators.debug.sensitive_post_parameters`, to allow
+designating the local variables and POST parameters that may contain sensitive
information and should be filtered out of error reports.
All POST parameters are now systematically filtered out of error reports for
View
32 docs/releases/1.4.8.txt
@@ -0,0 +1,32 @@
+==========================
+Django 1.4.8 release notes
+==========================
+
+*September 14, 2013*
+
+Django 1.4.8 fixes two security issues present in previous Django releases in
+the 1.4 series.
+
+Denial-of-service via password hashers
+--------------------------------------
+
+In previous versions of Django, no limit was imposed on the plaintext
+length of a password. This allowed a denial-of-service attack through
+submission of bogus but extremely large passwords, tying up server
+resources performing the (expensive, and increasingly expensive with
+the length of the password) calculation of the corresponding hash.
+
+As of 1.4.8, Django's authentication framework imposes a 4096-byte
+limit on passwords and will fail authentication with any submitted
+password of greater length.
+
+Corrected usage of :func:`~django.views.decorators.debug.sensitive_post_parameters` in :mod:`django.contrib.auth`’s admin
+-------------------------------------------------------------------------------------------------------------------------
+
+The decoration of the ``add_view`` and ``user_change_password`` user admin
+views with :func:`~django.views.decorators.debug.sensitive_post_parameters`
+did not include :func:`~django.utils.decorators.method_decorator` (required
+since the views are methods) resulting in the decorator not being properly
+applied. This usage has been fixed and
+:func:`~django.views.decorators.debug.sensitive_post_parameters` will now
+throw an exception if it's improperly used.
View
9 docs/releases/1.4.txt
@@ -507,10 +507,11 @@ docs </ref/contrib/csrf>` for more information.
Error report filtering
~~~~~~~~~~~~~~~~~~~~~~
-We added two function decorators, :func:`sensitive_variables` and
-:func:`sensitive_post_parameters`, to allow designating the local variables
-and POST parameters that may contain sensitive information and should be
-filtered out of error reports.
+We added two function decorators,
+:func:`~django.views.decorators.debug.sensitive_variables` and
+:func:`~django.views.decorators.debug.sensitive_post_parameters`, to allow
+designating the local variables and POST parameters that may contain sensitive
+information and should be filtered out of error reports.
All POST parameters are now systematically filtered out of error reports for
certain views (``login``, ``password_reset_confirm``, ``password_change`` and
View
40 docs/releases/1.5.4.txt
@@ -0,0 +1,40 @@
+==========================
+Django 1.5.4 release notes
+==========================
+
+*September 14, 2013*
+
+This is Django 1.5.4, the fourth release in the Django 1.5 series. It addresses
+two security issues and one bug.
+
+Denial-of-service via password hashers
+--------------------------------------
+
+In previous versions of Django, no limit was imposed on the plaintext
+length of a password. This allowed a denial-of-service attack through
+submission of bogus but extremely large passwords, tying up server
+resources performing the (expensive, and increasingly expensive with
+the length of the password) calculation of the corresponding hash.
+
+As of 1.5.4, Django's authentication framework imposes a 4096-byte
+limit on passwords, and will fail authentication with any submitted
+password of greater length.
+
+Corrected usage of :func:`~django.views.decorators.debug.sensitive_post_parameters` in :mod:`django.contrib.auth`’s admin
+-------------------------------------------------------------------------------------------------------------------------
+
+The decoration of the ``add_view`` and ``user_change_password`` user admin
+views with :func:`~django.views.decorators.debug.sensitive_post_parameters`
+did not include :func:`~django.utils.decorators.method_decorator` (required
+since the views are methods) resulting in the decorator not being properly
+applied. This usage has been fixed and
+:func:`~django.views.decorators.debug.sensitive_post_parameters` will now
+throw an exception if it's improperly used.
+
+Bugfixes
+========
+
+* Fixed a bug that prevented a ``QuerySet`` that uses
+ :meth:`~django.db.models.query.QuerySet.prefetch_related` from being pickled
+ and unpickled more than once (the second pickling attempt raised an
+ exception) (#21102).
View
16 docs/releases/1.6.txt
@@ -780,6 +780,22 @@ as JSON requires string keys, you will likely run into problems if you are
using non-string keys in ``request.session``. See the
:ref:`session_serialization` documentation for more details.
+4096-byte limit on passwords
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. note::
+ This behavior was also added in the Django 1.5.4 and 1.4.8 security
+ releases.
+
+Historically, Django has imposed no length limit on plaintext
+passwords. This enables a denial-of-service attack through submission
+of bogus but extremely large passwords, tying up server resources
+performing the (expensive, and increasingly expensive with the length
+of the password) calculation of the corresponding hash.
+
+Django now imposes a 4096-byte limit on password length, and will fail
+authentication with any submitted password of greater length.
+
Miscellaneous
~~~~~~~~~~~~~
View
8 docs/releases/1.7.txt
@@ -402,14 +402,6 @@ Miscellaneous
Rationale behind this is removal of dependency of non-contrib code on
contrib applications.
-* Passwords longer than 4096 bytes in length will no longer work and will
- instead raise a ``ValueError`` when using the hasher directory or the
- built in forms shipped with ``django.contrib.auth`` will fail validation.
-
- The rationale behind this is a possibility of a Denial of Service attack when
- using a slow password hasher, such as the default PBKDF2, and sending very
- large passwords.
-
Features deprecated in 1.7
==========================
View
2  docs/releases/index.txt
@@ -36,6 +36,7 @@ Final releases
.. toctree::
:maxdepth: 1
+ 1.5.4
1.5.3
1.5.2
1.5.1
@@ -46,6 +47,7 @@ Final releases
.. toctree::
:maxdepth: 1
+ 1.4.8
1.4.7
1.4.6
1.4.5
Please sign in to comment.
Something went wrong with that request. Please try again.