django's soup

[django] DjangoCon Europe 2012 is just 2 months away

Sat, 07 Apr 2012 04:00:00 GMT

[django] Django 1.4 released

Fri, 23 Mar 2012 17:05:49 GMT

[django] Django 1.4 release candidate 2 issued

Thu, 15 Mar 2012 01:43:12 GMT

[django] Django's future, and Python 3

Wed, 14 Mar 2012 00:44:49 GMT

Django's future, and Python 3

[django] Django 1.4 update

Wed, 14 Mar 2012 00:39:34 GMT

[django] DjangoCon Europe 2012 tickets on sale and call for papers

Tue, 06 Mar 2012 01:45:00 GMT

[django] Django 1.4 release candidate issued

Mon, 05 Mar 2012 17:37:13 GMT

[django] Django 1.4 beta 1 released

Thu, 16 Feb 2012 04:23:51 GMT

[django] Django Sprint in Kraków, Poland

Tue, 31 Jan 2012 13:55:00 GMT

[django] Django Software Foundation announces membership drive

Mon, 16 Jan 2012 12:45:00 GMT

[django] Django 1.4 alpha 1 released

Fri, 23 Dec 2011 04:30:26 GMT

[django] Announcing DjangoCon Europe 2012

Tue, 20 Dec 2011 17:35:46 GMT

[django] Piston and Tastypie security releases issued

Tue, 01 Nov 2011 16:08:32 GMT

[django] Django 1.2.7 released

Sat, 10 Sep 2011 23:09:56 GMT

[django] Security releases issued

Fri, 09 Sep 2011 23:50:11 GMT

[django] PyCon AU 2011 sprints

Fri, 19 Aug 2011 12:30:00 GMT

[django] DjangoCon 2011 is almost here

Tue, 16 Aug 2011 02:45:00 GMT

[django] DjangoCon US Call for Tutorial Proposals

Mon, 06 Jun 2011 07:40:00 GMT

[django] DjangoCon EU 2011 sprints

Sun, 05 Jun 2011 06:16:21 GMT

[django] Summer of Code 2011

Mon, 25 Apr 2011 20:54:14 GMT

[django] Django 1.3 released

Wed, 23 Mar 2011 06:09:02 GMT

[django] DjangoCon Europe 2011 tickets on sale

Thu, 17 Mar 2011 13:45:00 GMT

[django] Django 1.3 release candidate available

Fri, 04 Mar 2011 05:35:24 GMT

[django] Django 1.3 release schedule - Update 4

Wed, 16 Feb 2011 23:45:00 GMT

[django] Errata for yesterday's security release announcement

Thu, 10 Feb 2011 09:15:00 GMT

Errata for yesterday's security release announcement

[django] Security releases issued

Wed, 09 Feb 2011 03:26:17 GMT

[django] Django 1.3 release schedule - Update 3

Wed, 02 Feb 2011 14:30:00 GMT

[django] DjangoCon Europe 2011 announced

Fri, 14 Jan 2011 16:00:00 GMT

The DjangoCon Europe 2011 organizing committee, chaired by Remco Wendt, has just announced that DjangoCon Europe 2011 will be held in Amsterdam, the Netherlands, from June 6-10 2011. The conference itself will take place on June 6-8, the sprint days will be June 9-10. Though the word was already put out on twitter, the announcement is now available on the official site, http://www.djangocon.eu.

The conference venue is a former warehouse, part of the old port of Amsterdam. The sprint location is a place called "De Waag" which is an old castle in the very heart of Amsterdam, and is famous for housing the Amsterdam Guild of Surgeons during the 17th century.

The sprint location will be open for us 48-hours non stop, meaning literally that we can sprint until we drop.

Hope to see you in Amsterdam in June!

[django] Django 1.3 release schedule - Update 2

Wed, 05 Jan 2011 15:00:00 GMT

The first major task in ensuring a timely Django 1.3 release has been completed: the backlog of unreviewed tickets has been cleared. As of the time of writing, every ticket in Django's ticket tracker has undergone at least an initial review.

As a result, we can now give our first report on progress towards the 1.3 release. At the time of writing, there are 20 tickets known to be release blockers; for an up-to-date list, check this Trac query.

To be considered a release blocker, a ticket must describe a problem that:

is a regression in behavior from Django 1.2; or
demonstrates a design flow or bug in a feature added in Django 1.3; or
reveals a problem in Django's packaging or release procedures; or
can cause catastrophic and unintentional loss of data under easily reproducible circumstances.

Everything else is nice-to-have, but will not prevent us from releasing Django 1.3 on schedule.

The good news is that most of the release blocking tickets are relatively minor issues. They are either regressions that have occurred due to inadequate test coverage, or relatively minor oversights in features added in 1.3. As a result, we appear to be on schedule for an on-time release (i.e., release candidate in the week of January 24, Final in the week of January 31)

Once the release blocking tickets have been addressed, attention will turn to tickets that are Ready For Checkin. Ideally, there will be no Ready for Checkin bug fixes when we make the final 1.3 release -- all tickets in the Ready For Checkin queue will hopefully either be checked in, bumped back to Accepted because the proposed patch is flawed, or represent a feature than needs to wait for the 1.4 release cycle. We will reassess the Zero-RFC goal as we get closer to the release candidate deadline.

It's important to note that a ticket marked Milestone 1.3 is not automatically guaranteed to be part of the 1.3 release. If you have a ticket that is on Milestone 1.3 and you want to see it actually get committed to 1.3, then you need to get it reviewed by someone so it can progress to Ready For Checkin. If it isn't Ready For Checkin, it won't be checked in!

There's plenty to do if you want to help out:

Write a patch for a release blocking bug
Review someone else's 1.3 Milestone ticket
Write a patch for a 1.3 Milestone ticket (and get someone else to review it)
Proof read the documentation for errors, omissions, and typos
Run your own sites against trunk and report any regressions or problems
Try using new features and report any problems you encounter

The more help we get, the better the 1.3 release will be.

[django] Django 1.3 beta 1 released

Thu, 23 Dec 2010 04:36:45 GMT

As part of the Django 1.3 release process, tonight we've released Django 1.3 beta 1, a preview/testing package that gives a little taste of some of the new features coming in Django 1.3. 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.3, or if you'd like to pitch in and help us fix bugs before the final 1.3 release (due in January), feel free to grab a copy and give it a spin.

Also, note that this beta release contains the patches mentioned in the security announcement earlier today. If you're using Django 1.3 alpha 1, you're urged to upgrade to beta 1 or apply the trunk patches immediately.

You can get a copy of the 1.3 beta 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.3 beta package are available.

[django] Security releases issued

Thu, 23 Dec 2010 04:30:35 GMT

Today the Django team is issuing multiple releases -- Django 1.2.4, Django 1.1.3 and Django 1.3 beta 1 -- to remedy two security issues reported to us. All users of affected versions of Django are urged to upgrade immediately.

Information leakage in Django administrative interface

The Django administrative interface, django.contrib.admin, supports filtering of displayed lists of objects by fields on the corresponding models, including across database-level relationships. This is implemented by passing lookup arguments in the querystring portion of the URL, and options on the ModelAdmin class allow developers to specify particular fields or relationships which will generate automatic links for filtering.

One historically-undocumented and -unofficially-supported feature has been the ability for a user with sufficient knowledge of a model's structure and the format of these lookup arguments to invent useful new filters on the fly by manipulating the querystring.

As reported to us by Adam Baldwin, however, this can be abused to gain access to information outside of an admin user's permissions; for example, an attacker with access to the admin and sufficient knowledge of model structure and relations could construct querystrings which -- with repeated use of regular-expression lookups supported by the Django database API -- expose sensitive information such as users' password hashes.

To remedy this, django.contrib.admin will now validate that querystring lookup arguments either specify only fields on the model being viewed, or cross relations which have been explicitly whitelisted by the application developer using the pre-existing mechanism mentioned above. This is backwards-incompatible for any users relying on the prior ability to insert arbitrary lookups, but as this "feature" was never documented or supported, we do not consider it to be an issue for our API-stability policy. The release notes for Django 1.3 beta 1 -- which will include this change -- will, however, note this difference from previous Django releases.

Denial-of-service attack in password-reset mechanism

Django's bundled authentication framework, django.contrib.auth, offers views which allow users to reset a forgotten password. The reset mechanism involves generating a one-time token composed from the user's ID, the timestamp of the reset request converted to a base36 integer, and a hash derived from the user's current password hash (which will change once the reset is complete, thus invalidating the token).

The code which verifies this token, however, does not validate the length of the supplied base36 timestamp before attempting to convert it. An attacker with sufficient knowledge of a site's URL configuration and the manner in which the reset token is constructed can, then, craft a request containing an arbitrarily-large (up to the web server's maximum supported URL length) base36 integer, which Django will blindly attempt to convert back into a timestamp.

As reported to us by Paul McMillan, the time required to attempt this conversion on ever-larger numbers will consume significant server resources, and many such simultaneous requests will result in an effective denial-of-service attack. Further investigation revealed that the password-reset code blindly converts base36 in multiple places.

To remedy this, the base36_to_int() function in django.utils.http will now validate the length of its input; on input longer than 13 digits (sufficient to base36-encode any 64-bit integer), it will now raise ValueError. Additionally, the default URL patterns for django.contrib.auth will now enforce a maximum length on the relevant parameters.

Affected versions

Both of the issues described above are present in the following currently-supported Django versions:

Django development trunk
Django 1.2
Django 1.1

Resolution

Patches have been applied to Django trunk, and to the 1.2 and 1.1 release branches, which resolve both issues described above. The patches may be obtained directly from the appropriate changesets:

Django trunk: changeset 15031 for the admin issue and changeset 15032 for the password-token issue.
Django 1.2: changeset 15033 for the admin issue and changeset 15034 for the password-token issue.
Django 1.1: changeset 15035 for the admin issue and changeset 15036 for the password-token issue.

The following new releases have been issued:

Django 1.2.4 (download | checksums)
Django 1.1.3 (download | checksums)

Django 1.3 beta 1, which will contain the patch from Django trunk, will also be issued later today.

General notes regarding security

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

Due to the impending Christmas and New Year's holiday, our normal process of notifying distributors of Django one week in advance of security-releated release was shortened somewhat to allow these releases to be issued before most Django users take their holiday vacations.

If you are or represent a third-party distributor of Django and did not receive a notification email from the Django release manager, please contact james@b-list.org.

[django] Django 1.3 release schedule -- Update

Mon, 13 Dec 2010 08:00:00 GMT

Once again, astute observers will have noted a missed deadline: November 29 has come and gone, but Django 1.3 beta 1 hasn't been released.

In this case, the delay has been caused by a desire to deliver on everything that has been discussed over the last few months. The release of Beta 1 marks the full feature freeze for Django 1.3, and there are lots of little features that have been discussed at length, and are very close to completion, but haven't been committed to trunk. Rather than defer these features to the 1.4, we've opted to push the release schedule by a couple of weeks to let the last few commits happen.

At this point, the outstanding issues are:

#7817: Modification of the {% with %} to support multiple assignment
#9456: Modification of the {% include %} tag to support subtemplate assignment
#11675: Addition of a pylibmc cache backend
#14844: dealing with pluralization rules in {% blocktrans %}
Some administrative i18n issues, aimed at allowing translators to use Transifex to keep translations up to date

In order to accommodate these last features, we've decided to push the Beta 1 release until December 21.

To ensure that we have enough time for fixing bugs once the beta has been released, we're also going to push the final release date by 2 weeks. This means the 1.3 release candidate should be released on January 24, followed by a final 1.3 release on January 31.

Once the beta has been released, we will be focussing on bug fixes. We will be using the Ready For Checkin list as the working list, so if you have a bug you want to see fixed, make sure it has been reviewed and is correctly tagged for as being ready for checkin. We also need assistance triaging the list of unreviewed tickets.

If you're not sure what you need to do in order to get your ticket ready for checkin, read the contribution guide; we also have a work-in-progress HowTo guide that may help clarify what is needed. If you're still not sure, try asking on the #django-dev IRC channel for a push in the right direction.

[django] DjangoCon US 2011 announced!

Mon, 22 Nov 2010 06:30:00 GMT

The DjangoCon organizing committee, led by Steve Holden, has just announced that DjangoCon US 2011 will be held in Portland, Oregon, from September 6-8 2011. This will be followed by a couple of days of sprints. We are also exploring the possibility of running tutorials on the day before (September 5).

There will be a change of venue from the last two years -- we've shifted to the Hilton Portland and Executive Tower. This is located right in the middle of downtown Portland, so it should be a lot more convenient for dinner and other social activities.

The budget hasn't been finalized yet, but we will be aiming to keep registration fees comparable to DjangoCon US 2010. However, we have already negotiated complimentary internet for everyone staying at the hotel, and throughout the ballroom where the conference will be taking place.

Although there was some interest in looking at other venues, due to the relatively short time frame, it was necessary to stick to Portland for at least one more year. To that end -- if you are interested in hosting DjangoCon US 2012 in a location other than Portland, now is the time to start organizing. Jump on the DjangoCon organizers mailing list an let us know that you want to help out. And if you want to help organize DjangoCon US 2011, jump on the same list!

Hope to see you in Portland in September!

[django] Upcoming development sprints

Fri, 12 Nov 2010 01:30:00 GMT

In order to assist in the timely release of Django 1.3, we are holding a series of Django development sprints over the next couple of weeks.

This weekend, on Saturday November 13, there will be 2 sprints held in parallel. One sprint will be held at the betahaus coworking space in Berlin, Germany. The second will be at several locations around Argentina.

In three weeks time there will be another sprint -- this time, a 2 day sprint (December 4 and 5), held in Sydney, Australia. This sprint will be hosted by The Interaction Consortium.

If you can't make it to Argentina, Berlin, or Sydney in person, you can join us in the #django-sprint IRC channel and help out that way.

For more information on the plans for these sprints, please check out the wiki pages. If you plan on attending, please add your name to the list so that the organizers know how many people to expect. If you want to know what to work on, or you've never been sprinting before and want to know what to expect, check out the wiki page on ideas for sprints.

Hope to see you there!

[django] Django 1.3 alpha 1 released

Thu, 11 Nov 2010 07:31:43 GMT

As part of the Django 1.3 release process, tonight we've released Django 1.3 alpha 1, a preview/testing package that gives a little taste of some of the new features coming in Django 1.3. 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.3, or if you'd like to pitch in and help us fix bugs before the final 1.3 release (due in January), feel free to grab a copy and give it a spin.

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

[django] Django 1.3 alpha 1 -- Update

Mon, 25 Oct 2010 15:00:00 GMT

Astute observers will have noted that October 18 has come and gone, but Django 1.3 alpha 1 hasn't been released.

There are two reasons for this. Firstly, we landed a number of big features very close to the original planned release date, including class-based views, a static media framework, and a context manager for transactions. However, we're still seeing some sporadic bug reports for these features. We don't expect that the alpha will be bug-free, but we'd like to avoid cutting a release with any completely boneheaded mistakes in it, so we're going to wait a little bit for the dust to settle before we produce the alpha.

Secondly, James Bennett, our release manager, has been particularly busy of late, and hasn't been in a position to turn the crank handle that makes the release. Although our bus factor for making releases is low, it is greater than 1 -- if James is unable to find time to make the release once the time comes, there are a couple of other people on the core team (including myself and Jacob) that know how to produce a release should the need arise.

This delay only affects the alpha -- it doesn't change the overall schedule. With any luck, we should have an alpha by this time next week. After that, we're still targeting a beta (and full feature freeze) at the end of November, and a final release for January 17 next year. If you have a little feature that you want to see in Django 1.3, now is the time to make sure the your patch is in good condition, and join us on the Django-developers mailing list or on #django-dev on IRC to advocate for the features your want to see.

[django] Django 1.3 release schedule

Thu, 30 Sep 2010 15:30:00 GMT

Django 1.2 has been in the wild for a couple of months, and we've had plenty of time to talk about what we want to see in Django 1.3. That means it's time to pick features and nominate some deadlines.

From the feedback from DjangoCon, and from conversations on the mailing lists and IRC, it's fairly clear that people are happy with the new features that have been added with Django 1.1 and 1.2. However, there is also concern about the growing backlog of bugs and minor feature requests that have accrued while we work on these big features.

For this reason, Django 1.3 is going to be light on big new features, and heavy on bugfixes and little features. We'll still have a couple of big features -- most likely those features that have missed previous release, such as logging and class-based generic views. However, for the bulk of the release, we're going to try and focus on getting the open ticket count down.

Here's the release schedule:

October 18, 2010 -- Django 1.3 alpha; major feature freeze
November 29, 2010 -- Django 1.3 beta; complete feature freeze
January 10, 2011 -- Django 1.3 RC1; translation string freeze
January 17, 2011 -- Django 1.3 final

Full details, an explanation of the schedule, and suggestions on how to help out can be found in the 1.3 Roadmap.

So dig in! There's plenty of work to do, and the more volunteers we have, the better Django 1.3 will be!

[django] Django 1.2.3 released

Sat, 11 Sep 2010 04:54:52 GMT

Today the Django team has released Django 1.2.3, which remedies several issues with the recent 1.2.2 package.

This package corrects the following problems:

The patch applied for the security issue covered in Django 1.2.2 caused issues with non-ASCII responses using CSRF tokens. This has been remedied.
The patch also caused issues with some forms, most notably the user-editing forms in the Django administrative interface. This has been remedied.
The packaging manifest did not contain the full list of required files. This has been remedied.

All users of Django are encouraged to upgrade to Django 1.2.3 immediately; the 1.2.3 package can be obtained from the Django downloads page, and as always signed checksums for the package are available.

[django] Security release issued

Wed, 08 Sep 2010 22:46:56 GMT

Today the Django team is issuing a new release -- Django 1.2.2 -- to remedy a security issue reported to us. This issue was disclosed independently by two different parties, and all users of Django 1.2 are urged to upgrade immediately.

Description of issue

As of the 1.2 release, the core Django framework includes a system, enabled by default, for detecting and preventing cross-site request forgery (CSRF) attacks against Django-powered applications. Previous Django releases provided a different, optionally-enabled system for the same purpose.

The Django 1.2 CSRF protection system involves the generation of a random token, inserted as a hidden field in outgoing forms. The same value is also set in a cookie, and the cookie value and form value are compared on submission.

The provided template tag for inserting the CSRF token into forms -- {% csrf_token %} -- explicitly trusts the cookie value, and displays it as-is. Thus, an attacker who is able to tamper with the value of the CSRF cookie can cause arbitrary content to be inserted, unescaped, into the outgoing HTML of the form, enabling cross-site scripting (XSS) attacks.

This issue was first reported via a public ticket in Django's Trac instance; while being triaged it was then independently reported, with broader description, by Jeff Balogh of Mozilla.

Affected versions

Django development trunk
Django 1.2

Because the current CSRF-protection system is new as of Django 1.2, older releases are unaffected.

Resolution

Patches have been applied to Django trunk and to the 1.2 release branch to ensure the cookie value is never trusted and is always escaped. Future Django releases may migrate away from the use of a dedicated cookie to avoid the possibility of such issues.

Patches may be obtained directly from the appropriate changesets:

Django trunk: Changeset 13698
Django 1.2: Changeset 13699

The following release has been issued:

Django 1.2.2 (download | checksums)

General notes regarding security

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.

Due to the time-sensitive nature of this issue, our normal process of advance notification of distributors of Django was not followed; notification to distributors was sent just prior to issuance of this release. If you are or represent a third-party distributor of Django and did not receive a notification email from the Django release manager, please contact james@b-list.org.

[django] Django 1.2.1 released

Mon, 24 May 2010 19:25:31 GMT

As previously announced, today marks the release of Django 1.2.1, the first bugfix release in the Django 1.2 series. For the package itself, swing by our downloads page; and as always, signed checksums of the release package are available.

As a bugfix release, Django 1.2.1 contains no new features -- only the fixes for a few bugs noted in the previous announcements, along with two more tickets which had quick fixes available: #13592 and #13590.