mirror of
https://github.com/django/django.git
synced 2024-11-18 15:34:16 +00:00
17d3a6d804
Thanks João Silva for reporting the problem and Tim Graham for finding the problematic RE and for review. This is a security fix; disclosure to follow shortly.
156 lines
6.6 KiB
Plaintext
156 lines
6.6 KiB
Plaintext
==========================
|
||
Django 1.8.3 release notes
|
||
==========================
|
||
|
||
*July 8, 2015*
|
||
|
||
Django 1.8.3 fixes several security issues and bugs in 1.8.2.
|
||
|
||
Also, ``django.utils.deprecation.RemovedInDjango20Warning`` was renamed to
|
||
``RemovedInDjango110Warning`` as the version roadmap was revised to 1.9, 1.10,
|
||
1.11 (LTS), 2.0 (drops Python 2 support). For backwards compatibility,
|
||
``RemovedInDjango20Warning`` remains as an importable alias.
|
||
|
||
Denial-of-service possibility by filling session store
|
||
======================================================
|
||
|
||
In previous versions of Django, the session backends created a new empty record
|
||
in the session storage anytime ``request.session`` was accessed and there was a
|
||
session key provided in the request cookies that didn't already have a session
|
||
record. This could allow an attacker to easily create many new session records
|
||
simply by sending repeated requests with unknown session keys, potentially
|
||
filling up the session store or causing other users' session records to be
|
||
evicted.
|
||
|
||
The built-in session backends now create a session record only if the session
|
||
is actually modified; empty session records are not created. Thus this
|
||
potential DoS is now only possible if the site chooses to expose a
|
||
session-modifying view to anonymous users.
|
||
|
||
As each built-in session backend was fixed separately (rather than a fix in the
|
||
core sessions framework), maintainers of third-party session backends should
|
||
check whether the same vulnerability is present in their backend and correct
|
||
it if so.
|
||
|
||
Header injection possibility since validators accept newlines in input
|
||
======================================================================
|
||
|
||
Some of Django's built-in validators
|
||
(:class:`~django.core.validators.EmailValidator`, most seriously) didn't
|
||
prohibit newline characters (due to the usage of ``$`` instead of ``\Z`` in the
|
||
regular expressions). If you use values with newlines in HTTP response or email
|
||
headers, you can suffer from header injection attacks. Django itself isn't
|
||
vulnerable because :class:`~django.http.HttpResponse` and the mail sending
|
||
utilities in :mod:`django.core.mail` prohibit newlines in HTTP and SMTP
|
||
headers, respectively. While the validators have been fixed in Django, if
|
||
you're creating HTTP responses or email messages in other ways, it's a good
|
||
idea to ensure that those methods prohibit newlines as well. You might also
|
||
want to validate that any existing data in your application doesn't contain
|
||
unexpected newlines.
|
||
|
||
:func:`~django.core.validators.validate_ipv4_address`,
|
||
:func:`~django.core.validators.validate_slug`, and
|
||
:class:`~django.core.validators.URLValidator` are also affected, however, as
|
||
of Django 1.6 the ``GenericIPAddresseField``, ``IPAddressField``, ``SlugField``,
|
||
and ``URLField`` form fields which use these validators all strip the input, so
|
||
the possibility of newlines entering your data only exists if you are using
|
||
these validators outside of the form fields.
|
||
|
||
The undocumented, internally unused ``validate_integer()`` function is now
|
||
stricter as it validates using a regular expression instead of simply casting
|
||
the value using ``int()`` and checking if an exception was raised.
|
||
|
||
Denial-of-service possibility in URL validation
|
||
===============================================
|
||
|
||
:class:`~django.core.validators.URLValidator` included a regular expression
|
||
that was extremely slow to evaluate against certain invalid inputs. This regular
|
||
expression has been simplified and optimized.
|
||
|
||
Bugfixes
|
||
========
|
||
|
||
* Fixed ``BaseRangeField.prepare_value()`` to use each ``base_field``’s
|
||
``prepare_value()`` method (:ticket:`24841`).
|
||
|
||
* Fixed crash during :djadmin:`makemigrations` if a migrations module either
|
||
is missing ``__init__.py`` or is a file (:ticket:`24848`).
|
||
|
||
* Fixed ``QuerySet.exists()`` returning incorrect results after annotation with
|
||
``Count()`` (:ticket:`24835`).
|
||
|
||
* Corrected ``HStoreField.has_changed()`` (:ticket:`24844`).
|
||
|
||
* Reverted an optimization to the CSRF template context processor which caused
|
||
a regression (:ticket:`24836`).
|
||
|
||
* Fixed a regression which caused template context processors to overwrite
|
||
variables set on a ``RequestContext`` after it's created (:ticket:`24847`).
|
||
|
||
* Prevented the loss of ``null``/``not null`` column properties during field
|
||
renaming of MySQL databases (:ticket:`24817`).
|
||
|
||
* Fixed a crash when using a reverse one-to-one relation in
|
||
``ModelAdmin.list_display`` (:ticket:`24851`).
|
||
|
||
* Fixed quoting of SQL when renaming a field to ``AutoField`` in PostgreSQL
|
||
(:ticket:`24892`).
|
||
|
||
* Fixed lack of unique constraint when changing a field from
|
||
``primary_key=True`` to ``unique=True`` (:ticket:`24893`).
|
||
|
||
* Fixed queryset pickling when using ``prefetch_related()`` after deleting
|
||
objects (:ticket:`24831`).
|
||
|
||
* Allowed using ``choices`` longer than 1 day with ``DurationField``
|
||
(:ticket:`24897`).
|
||
|
||
* Fixed a crash when loading squashed migrations from two apps with a
|
||
dependency between them, where the dependent app's replaced migrations are
|
||
partially applied (:ticket:`24895`).
|
||
|
||
* Fixed recording of applied status for squashed (replacement) migrations
|
||
(:ticket:`24628`).
|
||
|
||
* Fixed queryset annotations when using ``Case`` expressions with ``exclude()``
|
||
(:ticket:`24833`).
|
||
|
||
* Corrected join promotion for multiple ``Case`` expressions. Annotating a
|
||
query with multiple ``Case`` expressions could unexpectedly filter out
|
||
results (:ticket:`24924`).
|
||
|
||
* Fixed usage of transforms in subqueries (:ticket:`24744`).
|
||
|
||
* Fixed ``SimpleTestCase.assertRaisesMessage()`` on Python 2.7.10
|
||
(:ticket:`24903`).
|
||
|
||
* Provided better backwards compatibility for the ``verbosity`` argument in
|
||
``optparse`` management commands by casting it to an integer
|
||
(:ticket:`24769`).
|
||
|
||
* Fixed ``prefetch_related()`` on databases other than PostgreSQL for models
|
||
using UUID primary keys (:ticket:`24912`).
|
||
|
||
* Fixed removing ``unique_together`` constraints on MySQL (:ticket:`24972`).
|
||
|
||
* Fixed crash when uploading images with MIME types that Pillow doesn't detect,
|
||
such as bitmap, in ``forms.ImageField`` (:ticket:`24948`).
|
||
|
||
* Fixed a regression when deleting a model through the admin that has a
|
||
``GenericRelation`` with a ``related_query_name`` (:ticket:`24940`).
|
||
|
||
* Reallowed non-ASCII values for ``ForeignKey.related_name`` on Python 3 by
|
||
fixing the false positive system check (:ticket:`25016`).
|
||
|
||
* Fixed inline forms that use a parent object that has a ``UUIDField`` primary
|
||
key and a child object that has an ``AutoField`` primary key
|
||
(:ticket:`24958`).
|
||
|
||
* Fixed a regression in the ``unordered_list`` template filter on certain
|
||
inputs (:ticket:`25031`).
|
||
|
||
* Fixed a regression in ``URLValidator`` that invalidated Punycode TLDs
|
||
(:ticket:`25059`).
|
||
|
||
* Improved `pyinotify` ``runserver`` polling (:ticket:`23882`).
|