23 Oct 2026

feedDjango community aggregator: Community blog posts

Issue 360: Python and Wagtail Security Releases

News

Python 3.15.1, 3.14.9 and 3.13.17 are now available

Expedited security releases on October 21, carrying pip 26.2.2 and certifi 2026.10.19 to drop the compromised eMudhra CA. 3.13 is the odd one out: it had just entered security-only mode, where pip is not normally updated, so the team cut fresh installers anyway. 3.15.1 is also 3.15's first maintenance release, with roughly 330 fixes from 117 contributors.

Information for Python users regarding the eMudhra / emSign CA certificate security incident

The emSign root was pulled from CA bundles after eMudhra's intermediate keys turned out to be insecure, leaving older clients open to man-in-the-middle attacks against PyPI and python.org. Upgrade now: certifi 2026.10.19, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, in every virtualenv and container image. pip is the one that matters most, since it always trusts its vendored bundle and distrusting the CA at the OS level will not help.

Eight Bits of Trust: eMudhra's CA Keys Cracked in Milliseconds

The technical story behind the advisory, and it is remarkable: each P-384 private key was 47 zero bytes followed by one non-zero byte, so Scott Helme recovered all eight in under a second on a laptop by trying 255 candidates. eMudhra blames a key ceremony script that generated a second weak keypair, picked up for the CSR because the names looked alike.

Wagtail CMS News

Wagtail 8.0.1, 7.4.4, and 7.0.10 security releases

All three landed on October 20 with the same four fixes: an authorization bypass across collections via privacy settings, formula injection in XLSX exports, mishandled ancestor restrictions in the Pages admin API, and stored XSS through third-party HTML editors. 8.0.1 adds a fifth, access restrictions on the API v3 pages endpoint, plus a batch of API v3 write fixes. Also out: 7.4.4 and 7.0.10.

Wagtail 8.1 RC1

The release candidate adds Python 3.15 support and drops 3.10. API v3 gains write support for TypedTableBlock and nested inline relations, an ImageRenditionField, and workflow operations for pages and snippets. Redirects are now auto-created only when a live page moves or is renamed; set WAGTAILREDIRECTS_AUTO_CREATE = 'always' to get the old behavior back.

Django Software Foundation

Quarterly contributor outreach

Tim Schilling posts the Steering Council's list of what needs hands for 6.2: testing CompositeField, plus review on a DEFAULT_PK_FIELD setting, moving models between apps, partitioned cookies, and HTTP QUERY support. A second list covers ideas needing technical vetting, including a task timeout API and import maps.

Django Steering Council Meeting, October 19

This week's agenda: the quarterly outreach message, the Sovereign Tech Agency Resilience Fund, the VectorField DEP, Memcached clients, Jazzband updates, and suggestions for the new Triage and Review Team.

Updates to Django

Last week we had 15 pull requests merged into Django by 10 different contributors - including 3 first-time contributors! Congratulations to Sanskar Kharya, Aman Kumar Jain and Helmi Lakhder for having their first commits merged into Django - welcome on board!

New in Django 6.2:

New in Django 6.1:

Sponsored

Django for Beginners, 6th Edition

The sixth edition was published this week, available in digital and paperback formats. It features two new chapters, completely updated for Django 6.1+, and more. Read the first four chapters for free to try it out.

Django Fellow Reports

Django Fellow Report - Jacob

Chasing a forum thread led Jacob Tyler Walls to merge a fix that reduces the cost of building many-to-many related managers. He also spotted the last tweaks needed for multiline template tags, drafted a security fix, and triaged a JSONField RecursionError on deeply nested input.

Django Fellow Report - Natalia

Natalia Bidart kept the djangodocs Sphinx cleanup and the DEP 20 release checklists moving, including CVE records that can name the first affected release per branch. The Triage and Review Team held its first meeting, and the Security and Triage teams both gained members.

Django Fellow Report - Sarah

A short week around coughs and colds, but Sarah Boyce landed CSP nonces in headers for streaming responses, corrected verbatim-block tokenization, and enforced integer expiry times for file-based sessions. She also added Lilian Tran to the security team and Shai Berger as a triager.

Python Software Foundation

Announcing Python Software Foundation Fellow Members for Q3 2026

Aldo Caneo, Donghee Na, Paul Moore, and Takayuki Shimizukawa join the Fellow roster, recognized together for maintaining libraries, writing educational material, organizing events, and mentoring. Q4 nominations close November 20, 2026; email psf-fellow at python.org with the nominee's accomplishments.

Checking email reputation, and allowing Outlook again

PyPI blocked outlook.com and hotmail.com outright in June 2024 after a bulk malware campaign, which caught legitimate users too. A donated reputation service from UserCheck now judges addresses individually, so both domains are allowed again; in its first month it rejected 62 disposable domains and 120+ throwaway addresses.

Wikis: Relaunched!

The Python, PSF, and Jython wikis went read-only in February after AI scrapers overwhelmed hosts partly still running Python 2. They are back as static sites on GitHub Pages, edited by pull request against psf/wiki, with write access going first to the old wikis' known stewards.

Articles

Django's Brightest Timeline

Tim Schilling argues Django's feature process has quietly come together: new-feature ideas live in a GitHub repo where emoji reactions act as votes, proposals get asked to prove themselves as third-party packages first, and Django Probe plus Praful Gulani's experimental-features GSoC work could decide what lands on usage data instead of advocacy.

Django: check version support with norwegianblue

Hugo van Kemenade's eol command pulls endoflife.date into a color-coded table, so eol django shows release, support, and end-of-life dates at a glance (6.1, 6.0, and 5.2 supported, 6.0 security-only). uv tool install norwegianblue, and it speaks Markdown, reStructuredText, and JSON for docs and scripts.

Your workers open a new Postgres connection for every task

Django's default CONN_MAX_AGE = 0 means every task a worker picks up opens its own Postgres connection, about 5ms, longer than claiming and running the task on a warm one. Set it to 600 or use a connection pool before you benchmark anything. The numbers come from django-ox's own vendor.

Automating Django deployments with Deployer

Stein Ove Helset replaces his SSH-and-run-the-commands routine with Deployer, a PHP tool that is happy to run manage.py: dep deploy builds a fresh release with its own virtualenv, runs checks, migrations, and collectstatic, then flips a current symlink and restarts Gunicorn. Shared .env and media survive between releases, and rolling back is one command.

How I decide which Python and Django versions I want to support

Matthias Kestenholz splits the question by context: projects track the current stable release or a pre-release, while the more foundational a library is, the further back it should reach. He drops versions to prune CI cost or to use something new, and lands on Python 3.10+ with Django 3.2 or 4.2+ for most packages.

Events

IndyPy: Django & FastAPI: What's Next?

Tuesday, November 24 at 7pm ET, hybrid from E-gineering in Indianapolis or over Zoom. Tim Schilling covers what's new in contributing to Django, and Calvin Hendryx-Parker argues batteries-included against speed in the Django/FastAPI debate. Register on Meetup for the in-person seat or the Zoom link.

Podcasts

Django Chat #208: Django in Space with Loes Crama

Loes Crama is a software engineer at cosine Measurement Systems, contributing to ESA's NewAthena mission. We discuss her lifelong interest in space and how her work combines software engineering, data engineering, and data science.

Videos

Django in Space with Loes Crama

Loes Crama is a software engineer at cosine Measurement Systems working on ESA's NewAthena mission, the subject of her DjangoCon Europe talk on how Django helps build the largest X-ray observatory yet. This Django Chat episode covers how she arrived at a job that combines software engineering, data engineering, and data science.

Sponsored

Reach 4,300+ Engaged Django Developers

Sponsor this newsletter to reach an active community of Python and Django developers.

Django Job Board

The PSF is hiring its next CPython Developer in Residence, alongside two senior Python roles, one AI-leaning in the US and one in Barcelona with relocation support.

CPython Developer in Residence at Python Software Foundation 🆕

Senior Software Engineer - Python, React & AI at Camden Kelly Staffing 🆕

Senior Python Engineer (Barcelona-based / Relocation support to Barcelona) at Manychat 🆕

Projects

django-ses/django-ses

A Django email backend for Amazon's Simple Email Service.

ivelum/djangoql

Advanced search language for Django admin.

Sponsor Django News

Reach 4,300+ Django developers every Friday. See sponsorship details and rates.

23 Oct 2026 3:00pm GMT

21 Oct 2026

feedDjango community aggregator: Community blog posts

How I decide which Python and Django versions I want to support

How I decide which Python and Django versions I want to support

A recent post on Mastodon got me thinking about what my philosophy for dropping support for old versions of Python and Django is. Here's the post:

🚨 Important Announcement 🚨

Going forward all my packages will only "officially" support maintained #Python versions. Meaning since October only 3.14 and now 3.15.

This has no effect on Django version support.

CVEs will be backported to older 🐍 releases.

- @codingjoe

I tend to support versions long past their End of Life date. I jokingly said that I should spend time upgrading old websites instead of spending time writing a rationale why not. I don't want to argue for my position, but maybe this post will serve as the place to point people towards when the question arises again in the future.

The short answer: it depends on whether I'm working on a project, on my own machine or on a library.

Projects

When working on projects I'm always updating to the current stable version or even the bleeding edge. I want the projects to be as future-proof as possible and I also want to give early feedback when stuff breaks.

As long as the server software allows it, I'm just going to use uv to install the newest Python version that all the packages I'm using support (or at least ship binary wheels for), because I enjoy not compiling software when deploying too damn much.

Developer workstations

When it comes to developer workstations I don't really have the patience for outdated software. I don't see a reason why developer tooling can't be up to date. This came up recently in the django-debug-toolbar issue tracker. I'm totally fine with requiring an up-to-date version of Python for our pre-commit hooks, for example.

Libraries

The more foundational and widely used a library (potentially) is, the more important it is to me that it supports basically everything which is reasonable.

I'm still using my libraries in older projects myself, so they have to work there. I want to use them in all environments, at least when I'm not paying a big price in terms of language features.

Other people may be stuck on older versions too. People can upgrade their software, but there may be situations (for example in managed hosting environments) where people cannot freely update the underlying managed server software. That isn't necessarily a problem security-wise as long as there are other measures in place protecting those services.

When people use my libraries, I might get additional eyes on the code, and possibly even contributions.

Supporting a large range of Django versions, for example 3.2 (reached EOL on 2024-04-01) up to the current main development branch, can be surprisingly easy when you do not reach too much into Django's internals or depend on features added only recently.

That said, when do I actually drop support for an old version of Python or Django? Generally speaking, I have two reasons:

🌳 Keeping CI time down 🌳

I like pruning the CI matrix so as to not spend too much compute and energy. The exceptions are packages such as django-debug-toolbar and django-tree-queries: they are widely used and have to work on a wide range of Python and Django versions and database engines, so the additional CI runs are worth it.

When I remove a version from the CI matrix I mostly raise the minimum version in the package metadata as well. I almost never use upper bounds for version ranges, but lower bounds I definitely do use.

Using new features, either because I want them or because I need them

Sometimes, I just really want to merge dictionaries using the nice a | b syntax. If this reasoning sounds whimsical to you, it is, but only partially. Programming cannot just be a job, everybody needs to have fun sometimes.

Sometimes, I really need some API or behavior Django has only introduced recently, such as the way bound fields work in forms. For example, form validation didn't go through bound fields before 4.0.

What that means right now

Most of my packages currently require Python 3.10 or newer and Django 3.2 or 4.2 or newer. Some of the less actively developed ones still go back as far as Python 3.8, simply because I haven't had a reason to touch them. Python and Django support are linked: Django 4.2 supports Python 3.8 to 3.12 while Django 6.0 requires Python 3.12, so the oldest Django version I support pretty much decides the oldest Python version worth testing.

What is the downside?

Supporting old versions makes it easier for people to put off upgrading. Some people just don't want to upgrade at all, and my libraries continuing to work on old versions certainly doesn't push them to do it. When they suddenly have to because all hell breaks loose (because of security problems or something like that) it's so much harder: they have a long way to go until they reach supported versions. That said, in my experience that's not a big problem with Django at all. On the other hand, when the projects still use npm packages from 2015… oh my.

The code is also less clean than it could be. Supporting old versions means compatibility shims, and it means not using some of the nicer features newer versions offer.

In the end, both approaches are reasonable, and both have their costs. You should do what brings you more joy.

21 Oct 2026 5:00pm GMT

Django in Space - Loes Crama

🔗 Links

📦 Projects

📚 Books

🎥 YouTube

21 Oct 2026 3:00pm GMT