$ the-wire · showcase
ThreadSensitiveContext gains nesting, Q.check() escapes logged DB errors
By RepoJournal · Filed · About Django · Composed from the cited sources · methodology
asgiref can now nest ThreadSensitiveContext with a caller-supplied executor, and Django's constraint validation stops writing raw user input into logs, alongside a CSP header fix that was silently loosening policies.
Allow nesting ThreadSensitiveContext. (#596) django/asgiref
ThreadSensitiveContext can now be nested when the caller provides an executor, so thread-sensitive work can be moved off the wrapping context's worker. The stated goal is to let transaction.atomic inside an async context run on its own thread, and therefore its own Connection, a long-standing gap tracked in ticket 33882.
Fixed #37433 -- Escaped database error messages logged by Q.check(). django/django
Q.check() now routes database error messages through log_message(), which escapes their content and trims large values, consistent with other logging call sites. Database errors can carry the values being validated, which often originate from user input, so this closes a path where that input landed unescaped in logs.
Fixed #37395 -- Emitted 'none' for CSP directives left empty by an unused nonce. django/django
When a CSP directive's only source was CSP.NONCE and the nonce was never used during rendering, build_policy() removed the sentinel and left the directive empty, so it dropped out of the header entirely and the browser fell back to default-src. It now emits 'none' for that directive instead of omitting it, keeping the policy as restrictive as the developer declared.
Fixed #37401 -- Used os.makedirs() for safe_makedirs() on Python 3.15+. django/django
safe_makedirs() now calls os.makedirs() directly on Python 3.15+, which added the parent_mode argument as the upstream fix for the issue behind CVE-2026-25674. The vendored copy differed from CPython only by an extra chmod() that ignored the process umask; the vendored code goes away once Python 3.14 support ends.
Fixed #37447 -- Fixed makemessages with non-ASCII file names on Windows. django/django
makemessages failed to find non-ASCII file names on Windows because Python 3.15's default UTF-8 mode wrote the temporary file list as UTF-8 while xgettext reads those paths as raw bytes in the ANSI code page. Also worth noting: both djangoproject.com and code.djangoproject.com bumped pip to 26.2.2 and code.djangoproject.com moved to Django 5.2.18.
