Fixes the following security issues:
CVE-2019-12308: AdminURLFieldWidget XSS¶
The clickable "Current URL" link generated by AdminURLFieldWidget displayed
the provided value without validating it as a safe URL. Thus, an
unvalidated value stored in the database, or a value provided as a URL query
parameter payload, could result in an clickable JavaScript link.
AdminURLFieldWidget now validates the provided value using URLValidator
before displaying the clickable link. You may customize the validator by
passing a validator_class kwarg to AdminURLFieldWidget.__init__(), e.g.
when using formfield_overrides.
Patched bundled jQuery for CVE-2019-11358: Prototype pollution¶
jQuery before 3.4.0, mishandles jQuery.extend(true, {}, ...) because of
Object.prototype pollution. If an unsanitized source object contained an
enumerable __proto__ property, it could extend the native Object.prototype.
The bundled version of jQuery used by the Django admin has been patched to
allow for the select2 library’s use of jQuery.extend().
For more details, see the release notes:
https://docs.djangoproject.com/en/dev/releases/2.1.9/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 426084e25f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
CVE-2019-6975: Memory exhaustion in django.utils.numberformat.format()
If django.utils.numberformat.format() – used by contrib.admin as well as the
the floatformat, filesizeformat, and intcomma templates filters – received a
Decimal with a large number of digits or a large exponent, it could lead to
significant memory usage due to a call to '{:f}'.format().
To avoid this, decimals with more than 200 digits are now formatted using
scientific notation.
https://docs.djangoproject.com/en/2.1/releases/2.1.6/
2.1.6 contained a packaging error, fixed by 2.1.7:
https://docs.djangoproject.com/en/2.1/releases/2.1.7/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bump to the latest release of the 1.11.x LTS series as 1.10.x is no longer
supported upstream:
https://www.djangoproject.com/download/
Fixes the following security issues:
- CVE-2017-12794: Possible XSS in traceback section of technical 500 debug
page (1.11.5)
- CVE-2018-6188: Information leakage in AuthenticationForm (1.11.10)
- CVE-2018-7536: Denial-of-service possibility in urlize and urlizetrunc
template filters (1.11.11)
- CVE-2018-7537: Denial-of-service possibility in truncatechars_html and
truncatewords_html template filters (1.11.11)
- CVE-2018-14574: Open redirect possibility in CommonMiddleware (1.11.15)
Also add a hash for the license file.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit fixes the warnings reported by check-package on the help
text of all package Config.in files, related to the formatting of the
help text: should start with a tab, then 2 spaces, then at most 62
characters.
The vast majority of warnings fixed were caused by too long lines. A
few warnings were related to spaces being used instead of a tab to
indent the help text.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes the following security issues:
Since 1.10.3:
CVE-2016-9013 - User with hardcoded password created when running tests on
Oracle
Marti Raudsepp reported that a user with a hardcoded password is created
when running tests with an Oracle database.
CVE-2016-9014 - DNS rebinding vulnerability when DEBUG=True
Aymeric Augustin discovered that Django does not properly validate the Host
header against settings.ALLOWED_HOSTS when the debug setting is enabled. A
remote attacker can take advantage of this flaw to perform DNS rebinding
attacks.
Since 1.10.7:
CVE-2017-7233 - Open redirect and possible XSS attack via user-supplied
numeric redirect URLs
It was discovered that is_safe_url() does not properly handle certain
numeric URLs as safe. A remote attacker can take advantage of this flaw to
perform XSS attacks or to use a Django server as an open redirect.
CVE-2017-7234 - Open redirect vulnerability in django.views.static.serve()
Phithon from Chaitin Tech discovered an open redirect vulnerability in the
django.views.static.serve() view. Note that this view is not intended for
production use.
Cc: Oli Vogt <oli.vogt.pub01@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We want to use SPDX identifier for license string as much as possible.
SPDX short identifier for BSD-3c is BSD-3-Clause.
This change is done using following command.
find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/BSD-3c/BSD-3-Clause/g'
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The recommended form is without the trailing slash. Buildroot will add a slash
between FOO_SITE and FOO_SOURCE as appropriate.
Reported-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
CVE-2015-0219 - incorrectly handled underscores in WSGI headers. A
remote attacker could possibly use this issue to spoof headers in
certain environments.
CVE-2015-0220 - incorrectly handled user-supplied redirect URLs. A
remote attacker could possibly use this issue to perform a cross-site
scripting attack.
CVE-2015-0221 - incorrectly handled reading files in
django.views.static.serve(). A remote attacker could possibly use this
issue to cause Django to consume resources, resulting in a denial of
service.
CVE-2015-0222 - incorrectly handled forms with ModelMultipleChoiceField.
A remote attacker could possibly use this issue to cause a large number
of SQL queries, resulting in a database denial of service.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The license is really a 3 clauses BSD license, so let's specify this
in python-django.mk.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas:
- Bump to Django 1.7.2, the latest available version;
- Support Python 3 in addition to Python 2.
- Use a download location from pypi.python.org since the download
location from djangoproject.com didn't work as is and is
impractical to use with Buildroot: the full URL of the tarball is
https://www.djangoproject.com/download/1.7.2/tarball/. I.e, it does
not end with the tarball file name.]
Signed-off-by: oli vogt <oli.vogt.pub01@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
