October archive

Django 1.5 alpha 1 released

October 25, 2012

As part of the Django 1.5 release process, today we've released Django 1.5 alpha 1, a preview/testing package that gives a little taste of some of the new stuff coming in Django 1.5. As with all alpha and beta packages, this is not for production use, but if you'd like to try out some of the new goodies coming in 1.5, or if you'd like to pitch in and help us fix bugs before the final 1.5 release (due in December), feel free to grab a copy and give it a spin.

You can get a copy of the 1.5 alpha package 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.5 alpha package are available.

Also, please note that Django 1.5 now requires a minimum of Python 2.6; Python 2.5 is no longer supported. Python 3.x releases, starting with Python 3.2, are experimentally supported in this release. For more information on Python 3 support, and the testing Django 1.5 will still need, see this blog post.

Django Software Foundation calls for board nominations

October 21, 2012

After many years of service to the Django Software Foundation (DSF), Jacob Kaplan-Moss has expressed a desire to stand down from his position on the DSF board.

Jacob was one of the founding members of the DSF board, and served as the President of the DSF from it's conception until June 2010. The Django Software Foundation would like to thank Jacob for his many years of diligent service.

Jacob won't be going too far - he will continue to be a BDFL and contributor to the Django code base; he will also continue as a the infrastructure coordinator for the DSF.

As a result of Jacob's resignation, the DSF is calling for nominations for a replacement board member.

Formal nominations for the open board seat may be made by any DSF member. If you're not a DSF member, and you've got an idea of someone you'd like to see on the DSF board, feel free to suggest the name - if someone in the official membership agrees with you, they can formally propose that name for nomination.

What does a DSF board member do? DSF board members are expected to participate in a monthly board teleconference, and follow up on any activities generated by that teleconference. Depending on the business presented to the board, this may result in additional work over the course of the month. The work will usually be administrative and organisational in nature -- for example, representing the board in legal discussions, or liaising with groups performing work on the DSF's behalf.

The call for nominees closes at 1200 UTC on November 11.

Of course, if you'd like to be involved in the formal nomination and voting process, you need to be a member of the DSF. Developer members are individuals appointed by the DSF board in recognition of their service to the Django community. Corporate members are those that have contributed financially to the DSF. If you are interested in becoming a corporate member of the DSF, you can find out more on our corporate membership page.

If you've got any other questions about the board election process, please get in touch.

Security releases issued

October 17, 2012

Today the Django team is issuing multiple releases -- Django 1.3.4 and Django 1.4.2 -- to remedy security issues reported to us.

All users are encouraged to upgrade Django immediately.

Host header poisoning

Some parts of Django -- independent of end-user-written applications -- make use of full URLs, including domain name, which are generated from the HTTP Host header. Some attacks against this are beyond Django's ability to control, and require the web server to be properly configured; Django's documentation has for some time contained notes advising users on such configuration.

Django's own built-in parsing of the Host header is, however, still vulnerable, as was reported to us recently. The Host header parsing in Django 1.3 and Django 1.4 -- specifically, django.http.HttpRequest.get_host() -- was incorrectly handling username/password information in the header. Thus, for example, the following Host header would be accepted by Django when running on "validsite.com":

Host: validsite.com:random@evilsite.com

Using this, an attacker can cause parts of Django -- particularly the password-reset mechanism -- to generate and display arbitrary URLs to users.

To remedy this, the parsing in HttpRequest.get_host() is being modified; Host headers which contain potentially dangerous content (such as username/password pairs) now raise the exception django.core.exceptions.SuspiciousOperation.

Documentation of HttpOnly cookie option

As of Django 1.4, session cookies are always sent with the HttpOnly flag, which provides some additional protection from cross-site scripting attacks by denying client-side scripts access to the session cookie.

Though not directly a security issue in Django, it has been reported that the Django 1.4 documentation incorrectly described this change, by claiming that this was now the default for all cookies set by the HttpResponse.set_cookie() method.

The Django documentation has been updated to reflect that this only applies to the session cookie. Users of Django are encouraged to review their use of set_cookie() to ensure that the HttpOnly flag is being set or unset appropriately.

Affected versions

The Host header issue described above is present in the following versions of Django:

  • Django 1.3 release series (all versions)
  • Django 1.4 release series (all versions)
  • Django master development branch (soon to become Django 1.5)

The HttpOnly cookie documentation issue is present in the following versions of Django:

  • Django 1.4 release series (all versions)
  • Django master development branch


Patches have been applied to Django's development master branch, and to the 1.4 and 1.3 release branches, which resolve the issues described above. The patches may be obtained directly from the following changesets:

  • Development master branch: commit for the Host header issue and commit for the HttpOnly cookie documentation issue.
  • Django 1.4: commit for the Host header issue and commit for the HttpOnly cookie documentation issue.
  • Django 1.3: commit for the Host header issue.

The following new releases have been issued:

As Django's development branch is currently in a pre-alpha state, users are strongly advised not to be running production deployments from it; if you are currently doing so, however, you are urged to upgrade imediately to the latest HEAD, which contains the above patches.


The Host header issue was reported by James Kettle. The HttpOnly cookie documentation issue was reported by Preston Holmes, who is now a committer on Django.

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance or the django-developers list. Please see our security policies for further information.

Django Sprint in Stockholm, Sweden

October 10, 2012

I’m very happy to announce that there will be a two-day Django sprint on November 17-18 in Stockholm, Sweden. Thanks to the Django Software Foundation Django core developer Jannis Leidel will be there in person to help out. Organized by the Django Stockholm Meetup Group.

The sprint will be focused on Django 1.5 RC1, helping out getting it as stable and bug-free as possible. It’s scheduled for release on November 26, one week after the sprint. It's also possible to work on 1.6.

The venue is Fyndiq office, located in the Stockholm city centre and has 50 spots. The sprint will start at 10 AM CET on Saturday and finish Sunday evening. There will also be a chance to hang out together at the location the night before the sprint on Friday with drinks and snacks.

Register yourself if you want to attend in person. More information can also be found on the Django wiki sprint page.

If you’re unable get to Stockholm in person you are invited to participate online from wherever you are. Add your name under Roster in the sprint page. Core developers will be available in the Freenode IRC channel #django-sprint in order to review tickets and to assist you in the sprinting process.

We hope you can join us and help make the sprints as successful as possible.