July archive

Django 1.1 released

July 29, 2009

After nearly a year of development, lots of new features and thousands of other improvements, Django 1.1 is here and ready for prime time!

For a full rundown of what's new and what's changed, consult the release notes; to grab a copy, swing by the Django download page. And for the security-conscious, signed checksums for the release tarball are available.

This release also contains the security update rolled out earlier tonight for older release series.

Django 1.1 is the result of hard work by hundreds of people who've contributed code to Django and many more who've donated their time to reporting, triaging, tracking down and helping to fix bugs and develop new features. Django literally would not be able to happen without all of you, so stop and give yourselves (and any other contributors you know) a pat on the back.

Thanks once again to everyone who's helped out, and we hope to see you all at DjangoCon 2009 in Portland, Oregon, and all along the path to Django 1.2.

Security updates released

July 28, 2009

In accordance with our security policy, today the Django project is issuing a set of releases to remedy a vulnerability reported to us. This announcement contains a description of the vulnerability, a description of the changes made to fix it, and pointers to the patches for each supported version of Django.

Also covered here is an unrelated issue which, though security-related and resulting in changes to future Django releases, is not being treated as a vulnerability in Django itself.

Description of vulnerability

Django includes a lightweight, WSGI-based web server for use in learning Django and in testing new applications during early stages of development. For sake of convenience, this web server automatically maps certain URLs corresponding to the static media files used by the Django administrative application.

The handler which maps these URLs did not properly check the requested URL to verify that it corresponds to a static media file used by Django. As such, a carefully-crafted URL can cause the development server to serve any file to which it has read access.

By default, the development server does not listen on interfaces other than the local IPv4 loopback, and Django's documentation has and will continue to have stern warnings against the use of the development server in other situations (e.g., listening on a publicy- or network-accessible interface), and stating that the development server is not considered secure or performant enough for such use.

Affected versions

  • Django development trunk
  • Django 1.0
  • Django 0.96


The development server's admin media handler has been patched to verify that the requested URL corresponds to a static media file which should be served, and to properly emit an HTTP 404 ("File Not Found") response when the URL does not correspond to such a file.

Patches were applied in the following changesets:

The following releases are being issued immediately:

These releases are strongly encouraged upgrades for all users of affected versions of Django.

The final release of Django 1.1, due within hours of these releases, will include the above patch from the development trunk.

Secondary issue

A common deployment strategy for Django in some types of hosting environments involves placing the server which handles Django behind some other web server, which then acts as an HTTP proxy. In such situations, the REMOTE_ADDR environment variable is typically the IP address of the proxy. For convenience, Django includes an optional middleware class -- django.middleware.http.SetRemoteAddrFromForwardedFor -- which updates the value of REMOTE_ADDR based on the HTTP X-Forwarded-For header commonly set by some proxy configurations.

It has been demonstrated that this mechanism cannot be made reliable enough for general-purpose use, and that (despite documentation to the contrary) its inclusion in Django may lead application developers to assume that the value of REMOTE_ADDR is "safe" or in some way reliable as a source of authentication.

While not directly a security issue (since relying on REMOTE_ADDR or similar values is widely known to be a worst practice), the Django team has decided to deprecate and begin the process of removing this middleware with the Django 1.1 release.

This middleware class will be left as-is in the 1.0 and 0.96 release series, but in the 1.1 release series it will be replaced with a class which takes no action other than raising a deprecation error. It is expected that this placeholder warning class will be removed in the Django 1.2 release series.


Please note that the release of Django 1.1 will trigger end-of-life for the Django 0.96 release series; as such, Django 0.96.4 will be the last official release in that series and it will no longer receive bugfix or security support directly from the Django development team.

Django 1.1 release candidate available

July 21, 2009

As part of the Django 1.1 release process, tonight we've released Django 1.1 release candidate 1, a preview/testing package which, hopefully, is quite close to what will constitute the final Django 1.1 release. As with all pre-release packages, this is not for production use, but if you'd like to try out some of the new goodies coming in 1.1, or if you'd like to pitch in and help us fix bugs before the final 1.1 release (due in approximately one week), feel free to grab a copy and give it a spin.

You can get a copy of the 1.1 RC from our downloads page, and we recommend you read the release notes. Also, for the security conscious, signed MD5 and SHA1 checksums of the 1.1 release candidate package are available.

If no show-stopping bugs are found, the Django 1.1 final release will take place in one week. In the meantime, only critical release-blocking bugs will be considered for the final release. Django 1.1 is also now in string freeze; strings marked for translation will not change between now and the final release, so if you have translations to contribute now's the time.

With luck, we'll see you back here in a week for the release of Django 1.1.

DjangoCon 2009

July 13, 2009

Has it really been a year since DjangoCon 2008? Apparently so: registration for DjangoCon 2009 is now open! I'll let the conference chair, Robert Lofthouse, take over from here:

DjangoCon '09 will be in Portland, Oregon at the DoubleTree Green Hotel between 8th and 12th September. The first 3 days are conference days and the last 2 days are sprint days.

The keynote speakers will be:

Registration is now open, and early bird rates are available through this Sunday, July 19th. The call for talk submissions is open through the 1st of August. You can keep up to date with the latest news at djangocon.org.

DjangoCon '08 was a success at Google HQ in Mountain View (see videos from DjangoCon '08) and I'm sure we're going to have a lot of fun this time around as well.

Hope to see you there!

— Robert Lofthouse, DjangoCon Chairman