head	1.3;
access;
symbols
	pkgsrc-2026Q2:1.3.0.2
	pkgsrc-2026Q2-base:1.3;
locks; strict;
comment	@# @;


1.3
date	2026.06.04.09.21.12;	author adam;	state Exp;
branches;
next	1.2;
commitid	GAoP1cVniirLGsIG;

1.2
date	2026.05.13.12.12.58;	author adam;	state Exp;
branches;
next	1.1;
commitid	xb698ABNcG6wlEFG;

1.1
date	2026.04.22.07.26.16;	author adam;	state Exp;
branches;
next	;
commitid	Zvv6QPWQz1P1rVCG;


desc
@@


1.3
log
@py-django5: updated to 5.2.15

Django 5.2.15 fixes five security issues with severity “low” in 5.2.14.

CVE-2026-6873: Signed cookie salt namespace collision

get_signed_cookie() derived the signing salt by concatenating the cookie name (key) and salt arguments. When distinct name and salt pairs produced the same concatenation, cookies could be accepted in a context different from the one where they were signed.

Cookies are now signed with an unambiguous salt derivation. For backwards compatibility, cookies signed by older Django versions are accepted until Django 7.0. Projects affected by the above ambiguity should set SIGNED_COOKIE_LEGACY_SALT_FALLBACK to False to reject older cookies immediately.

This issue has severity “low” according to the Django security policy.

CVE-2026-7666: Potential unencrypted email transmission via STARTTLS in the SMTP backend

When using EMAIL_USE_TLS, a failed STARTTLS handshake could leave a partially-initialized connection that would subsequently be reused for sending email without encryption. This can occur with fail_silently=True, as used by send_mail() and BrokenLinkEmailsMiddleware, among others. Connections configured with EMAIL_USE_SSL are not affected.

This issue has severity “low” according to the Django security policy.

CVE-2026-8404: Potential exposure of private data via case-sensitive Cache-Control directives

UpdateCacheMiddleware and cache_page() incorrectly cached responses marked with private Cache-Control directives when using mixed or uppercase values (e.g. Private).

The cache_control() decorator and patch_cache_control() function were not affected, since they normalize directives to lowercase. This issue only affects responses where Cache-Control is set manually.

This issue has severity “low” according to the Django security policy.

CVE-2026-35193: Potential exposure of private data via missing Vary: Authorization

UpdateCacheMiddleware and cache_page() decorator allowed responses to requests bearing an Authorization header (and without Cache-Control: public) to be cached. To conform with the existing mechanism for constructing cache keys, responses to these requests will now vary on Authorization.

This issue has severity “low” according to the Django security policy.

CVE-2026-48587: Potential exposure of private data via whitespace padding in Vary header

UpdateCacheMiddleware incorrectly cached responses whose Vary header values contained leading or trailing whitespace. Because has_vary_header() failed to strip that, a Vary: * header value with surrounding whitespace was not recognized as containing the wildcard, causing it to be stored and potentially served from the cache when it should not have been.

This issue has severity “low” according to the Django security policy.
@
text
@# $NetBSD: Makefile,v 1.2 2026/05/13 12:12:58 adam Exp $

DISTNAME=	django-5.2.15
PKGNAME=	${PYPKGPREFIX}-${DISTNAME}
CATEGORIES=	www python
MASTER_SITES=	https://www.djangoproject.com/m/releases/${PKGVERSION_NOREV:R}/
MASTER_SITES+=	${MASTER_SITE_PYPI:=D/Django/}

MAINTAINER=	pkgsrc-users@@NetBSD.org
HOMEPAGE=	https://www.djangoproject.com/
COMMENT=	Django, a high-level Python Web framework
LICENSE=	modified-bsd

TOOL_DEPENDS+=	${PYPKGPREFIX}-setuptools>=78:../../devel/py-setuptools
DEPENDS+=	${PYPKGPREFIX}-asgiref>=3.8.1:../../www/py-asgiref
DEPENDS+=	${PYPKGPREFIX}-sqlparse>=0.3.1:../../databases/py-sqlparse

USE_LANGUAGES=	# none

PY_RENAME_BINARIES=	django-admin
REPLACE_PYTHON+=	django/conf/project_template/manage.py-tpl

.include "../../lang/python/application.mk"
.include "../../lang/python/wheel.mk"
.include "../../mk/bsd.pkg.mk"
@


1.2
log
@py-django5: updated to 5.2.14

Django 5.2.14 fixes three security issues with severity “low” in 5.2.13.

CVE-2026-5766: Potential denial-of-service vulnerability in ASGI requests via file upload limit bypass¶

ASGI requests with a missing or understated Content-Length header could bypass the FILE_UPLOAD_MAX_MEMORY_SIZE limit, potentially loading large files into memory and causing service degradation.

As a reminder, Django expects a limit to be configured at the web server level rather than solely relying on FILE_UPLOAD_MAX_MEMORY_SIZE.

This issue has severity “low” according to the Django security policy.

CVE-2026-35192: Session fixation via public cached pages and SESSION_SAVE_EVERY_REQUEST¶

Response headers did not vary on cookies if a session was not modified, but SESSION_SAVE_EVERY_REQUEST was True. A remote attacker could steal a user’s session after that user visits a cached public page.

This issue has severity “low” according to the Django security policy.

CVE-2026-6907: Potential exposure of private data due to incorrect handling of Vary: * in UpdateCacheMiddleware¶

Previously, UpdateCacheMiddleware would erroneously cache requests where the Vary header contained an asterisk ('*'). This could lead to private data being stored and served.
@
text
@d1 1
a1 1
# $NetBSD: Makefile,v 1.1 2026/04/22 07:26:16 adam Exp $
d3 1
a3 1
DISTNAME=	django-5.2.14
@


1.1
log
@py-django5: updated to 5.2.13

5.2.13

Django 5.2.13 fixes one security issue with severity “moderate” and four security issues with severity “low” in 5.2.12.
@
text
@d1 1
a1 1
# $NetBSD$
d3 1
a3 1
DISTNAME=	django-5.2.13
@