Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

December 28 2016

Django Fellowship Program: 2016 retrospective

2016 concludes my second year working full-time to support the development of Django. Here are some highlights from my weekly summaries published on the django-developers mailing list.

On the infrastructure front, I keep Django's continuous integration servers running smoothly, including the pull request checks that help keep code quality high and allow reviewers to focus on less trivial concerns. I also upgraded the djangoproject.com website to Django 1.10 and contributed several patches to third-party dependencies. I moved two under-maintained community sites, Django People and Django Snippets, to the djangoproject GitHub organization and upgraded them to supported versions of Django.

In Django's ticket tracker, I triage around 10-15 new tickets each week. A working knowledge of the 1000+ accepted tickets allows me to quickly identify duplicate and related issues and steer contributors in the right direction.

I coordinate security releases by preparing patches and backporting them to all supported versions of Django. In 2016, seven security issues were promptly fixed over five releases.

Django 1.10 marked the third consecutive on-time major release. As the release manager, I send regular email updates on the status of release blockers to django-developers, and I fix blockers when no one else has time or interest.

The Django 1.11 alpha is scheduled for mid-January with the final release scheduled for April 1. Following the 1.11 alpha release, the master development branch will target Django 2.0 and drop support for Python 2.7. I'm excited to see the simplifications and improvements we'll be able to make as a result.

Over the Python 3.6 prerelease period, I ensured compatibility with the Django master branch, including contributing several fixes and improvements for Python.

I co-mentored a Google Summer of Code project by Akshesh Doshi to add support for class-based indexes. This work is included in Django 1.11. I also made the final push to finish the template-based widget rendering patch that Preston Timmons started several years ago, and this is also included in 1.11.

While working toward the 1.11 feature release, we've had monthly bug fix releases for the 1.10 branch that have fixed over 40 regressions or bugs in new features.

On the code review front, I review an average of fifteen non-trivial patches a week from community members. Providing timely code reviews helps prevent would-be contributors from abandoning us.

I hope that gives you a good taste of what I've been doing. As always, please encourage your employer to become a corporate member of the Django Software Foundation and consider a gift to the Django Software Foundation to allow the fellowship to continue. I'm grateful for this opportunity and for the community's support. Thank you!

December 22 2016

DSF announces winner of the 2016 Malcolm Tredinnick Memorial Prize

The Django Software Foundation (DSF) is proud to announce the winner of the 2016 Malcolm Tredinnick Memorial Prize: Aisha Bello!

Aisha (@AishaXBello) joined the Django community when she attended a Django Girls workshop during EuroPython in 2015. From that point on, Aisha's trajectory in the Django world was unstoppable.

She is not only a talented developer but her desire to keep learning and sharing her knowledge with others is simply inspiring.

She organized or helped organize a huge number of Django Girls workshop in her home country of Nigeria. Thanks to her, Nigeria is on its way to be the world-record holder of most Django Girls events organized.

She's coached at other Django Girls events, introducing even more people to our community.

She's spoken at several conferences (including PyCon Namibia and DjangoCon US) sharing her unique knowledge and insight with the rest of us.

You can read more about her and her history at Your Django Story: Meet Aisha Bello.

She embodies the values of the Malcolm Tredinnick prize and we can't wait to see what she will achieve in the future.

Congratulations Aisha!

Sponsored post
Reposted bySchrammelhammelMrCoffeinmybetterworldkonikonikonikonikoniambassadorofdumbgroeschtlNaitliszpikkumyygittimmoe

December 04 2016

Presenting DjangoCon Europe 2017

2017’s DjangoCon Europe takes place against the gorgeous backdrop of Florence in the springtime. Once again the event will be organised by a local committee of volunteers on behalf of the global Django community.

The event will be held in the historic Odeon Cinema in the centre of the city. It’s an architectural gem, an Art Deco interior in a Renaissance palace.

Key points

Ticket sales are now open. Early-bird rates are available until the 17th January.

The call for proposals is open too, until the 31st December.

Generous financial assistance packages are offered, to help ensure that everyone who will benefit has the opportunity to attend.

The conference can even offer discounted public transport passes (see the tickets page) valid for the duration of the event, to help you get around the city.

The call for proposals

The programme of talks will represent the vibrant diversity of interests and endeavours across the Django community, including some that you had not only never heard of, but would not have imagined. The speaker roster will also feature some of the best-known names in the world of Django. There’ll be talks from those who are leading its development into the future, and about its deepest internals - discussions on the highest technical level.

The organisers invite proposals from all. Whatever your level of technical or speaking experience, you are invited to share what you know or have done with Django with your friends and colleagues in the community.

Both the speaker line-up and the selection of talks will be curated to offer a wide and representative balance, so the platform created by DjangoCon Europe 2017 will have room for everyone.

And just in case five days in Florence are not enough, PyCon Italia immediately follows DjangoCon Europe. You’re invited to submit your talk proposal to PyCon Italia too, in the same process, by ticking a single box on the form.

The ambitions of DjangoCon Europe 2017

The conference

Each successive DjangoCon Europe has advanced new ideas about how a conference should be run and has set new standards for itself. Just measuring up to past editions is challenge enough, but the organisers of 2017’s event have ambitions for it of their own, that also extend beyond this gathering of nearly 400 Djangonauts.

The Italian context

The organisers consider DjangoCon Europe 2017 an opportunity for the whole Italian Django community to use it as a launching pad for future organisation, development and activity, so that it makes a tangible and material difference to the open-source software community and industry in Italy.

The social context

The organisers want the event to harness the energy, know-how and organisation skills in the community, and put them to work in local organisations that work to advance social inclusion, in particular, amongst women from immigrant communities, who are disproportionately marginalised and excluded socially, technologically, economically and educationally.

Responsibility and sustainability

The Django community has always generally been conscious that its technology exists in a social context and not a vacuum.

The overall themes of this DjangoCon Europe are responsibility and sustainability: responsibility to others in our industry and of our industry’s responsibility to the wider world, and the sustainability - economic, personal and social - of the industry itself.

The conference invites its attendees to participate in these discussions, and to consider how our technology’s long-term viability depends on them as much as it does on the technical brilliance of its technologists.

A Django festival of ideas and collaboration

These are ambitions and aspirations. Their vehicle will be the international festival of community that each DjangoCon Europe represents, and reinvests with new energy each year. The organisers give you Florence in the springtime, a magnificent capital of history, culture, beauty and food, and the perfect foundation for building the future with Django.

Don’t miss it.

December 01 2016

Django bugfix release issued: 1.10.4, 1.9.12, 1.8.17

Today we've issued the 1.10.4, 1.9.12, and 1.8.17 bugfix releases.

The release package and checksums are available from our downloads page, as well as from the Python Package Index. The PGP key ID used for this release is Tim Graham: 1E8ABDC773EDE252.

July 08 2015

Security releases issued: 1.8.3, 1.7.9, 1.4.21

In accordance with our security release policy, the Django team is issuing multiple releases -- Django 1.4.21, 1.7.9, and 1.8.3. These releases are now available on PyPI and our download page. These releases address several security issues detailed below. We encourage all users of Django to upgrade as soon as possible. The Django master branch has also been updated.

Denial-of-service possibility by filling session store

In previous versions of Django, the session backends created a new empty record in the session storage anytime request.session was accessed and there was a session key provided in the request cookies that didn't already have a session record. This could allow an attacker to easily create many new session records simply by sending repeated requests with unknown session keys, potentially filling up the session store or causing other users' session records to be evicted.

The built-in session backends now create a session record only if the session is actually modified; empty session records are not created. Thus this potential DoS is now only possible if the site chooses to expose a session-modifying view to anonymous users.

As each built-in session backend was fixed separately (rather than a fix in the core sessions framework), maintainers of third-party session backends should check whether the same vulnerability is present in their backend and correct it if so.

Thanks Eric Peterson and Lin Hua Cheng for reporting the issue.

This issue has been assigned the identifier CVE-2015-5143.

Header injection possibility since validators accept newlines in input

Some of Django's built-in validators (django.core.validators.EmailValidator, most seriously) didn't prohibit newline characters (due to the usage of $ instead of \Z in the regular expressions). If you use values with newlines in HTTP response or email headers, you can suffer from header injection attacks. Django itself isn't vulnerable because django.http.HttpResponse and the mail sending utilities in django.core.mail prohibit newlines in HTTP and SMTP headers, respectively. While the validators have been fixed in Django, if you're creating HTTP responses or email messages in other ways, it's a good idea to ensure that those methods prohibit newlines as well. You might also want to validate that any existing data in your application doesn't contain unexpected newlines.

django.core.validators.validate_ipv4_address(), django.core.validators.validate_slug(), and django.core.validators.URLValidator are also affected, however, as of Django 1.6 the GenericIPAddresseField, IPAddressField, SlugField, and URLField form fields which use these validators all strip the input, so the possibility of newlines entering your data only exists if you are using these validators outside of the form fields.

The undocumented, internally unused validate_integer() function is now stricter as it validates using a regular expression instead of simply casting the value using int() and checking if an exception was raised.

Thanks Sjoerd Job Postmus for reporting the issue.

This issue has been assigned the identifier CVE-2015-5144.

Denial-of-service possibility in URL validation

django.core.validators.URLValidator included a regular expression that was extremely slow to evaluate against certain inputs. This regular expression has been simplified and optimized.

Thanks João Silva and Ross Brunton for reporting the issue.

This issue has been assigned the identifier CVE-2015-5145.

Affected supported versions

  • Django master development branch
  • Django 1.8
  • Django 1.7 (except the URL DoS issue)
  • Django 1.4 (except the URL DoS issue)

Per our supported versions policy, Django 1.5 and 1.6 are no longer receiving security updates.


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

On the development master branch:

On the 1.8 release branch:

On the 1.7 release branch:

On the 1.4 release branch:

The following new releases have been issued:

Note: The first 1.7.9 wheel file that we uploaded was corrupt (it contained some files from 1.8). A corrected file was uploaded about 2 hours after the initial release.

The PGP key ID used for these releases is Tim Graham: 1E8ABDC773EDE252.

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.

June 29 2015

Security advisory: simple_tag does not do auto-escaping

As per our documentation, the simple_tag decorator used for creating custom template tags does not run auto-escaping on its contents (up to and including Django 1.8). The team has noticed, however, that this makes it very easy to introduce XSS vulnerabilities when using simple_tag, and we have found examples of vulnerable code in the wild.

For this reason, Django 1.9 will change this behavior to improve security. In the mean time, all users are encouraged to check every usage of simple_tag in their own template tags and ensure they are not vulnerable, as per the instructions in the 1.9 release notes.

June 25 2015

Django's Roadmap

Following over 3,000 responses to the Django Developers Community Survey and a long discussion on the django-developers mailing list, the Django team has adopted the following release schedule (subject to change as needed).

The plan is to have a new feature release every 8 months and a new long-term support release (LTS) every 2 years. LTS releases are supported with security updates for 3 years.

Release Series Release Date End of mainstream support1 End of extended support2 1.9 December 2015 August 2016 April 2017 1.10 August 2016 April 2017 December 2017 1.11 LTS April 2017 December 2017 Until at least April 2020 2.0 December 2017 August 2018 April 2019

[1] Security fixes, data loss bugs, crashing bugs, major functionality bugs in newly-introduced features, and regressions from older versions of Django.
[2] Security fixes and data loss bugs.

The community was equally split between a twelve and six month release schedule, and we believe eight months is a good compromise. It also makes the release dates align well in terms of having a new LTS every 2 years.

As outlined in our supported versions policy, mainstream support for each feature release (which includes security fixes, data loss bugs, crashing bugs, major functionality bugs in newly-introduced features, and regressions from older versions of Django) lasts until the next feature release is issued (8 months unless delayed). Extended support (which includes security fixes and data loss bugs) lasts until the following feature release (another 8 months unless delayed).

The team has also decided to tweak our deprecation policy in order to ease upgrades from one LTS to the next and to allow third-party apps to more easily support the currently supported Django versions. We observed that most third-party apps didn't consider dropping support for the previous LTS (1.4) until the next LTS (1.8) was released. This meant that all these projects had to implement their own compatibility shims (instead of using Django's) once they wanted to add support for Django 1.6+ because the compatibility shims for deprecated features in Django 1.4 were dropped. This resulted in ugly code with lots of conditional version branches.

The new policy should make it easy to develop an app using the latest LTS release and have it continue to work without many changes until the next LTS. With this schedule, if you start with 1.8 you are already on LTS. If you start with 1.9, you should have an easy upgrade path all the way until 1.11 which will be an LTS release. Also upgrading from LTS to LTS (1.8 to 1.11) should be easy enough if you don't use any deprecated features when running on 1.8.

In order to reflect our new commitment to supporting compatibility shims in a way that eases maintenance of 3rd-party apps and upgrading projects from one LTS release to the next, we'll adopt a loose form of semantic versioning effective with Django 2.0. SemVer makes it easier to see at a glance how compatible releases are with each other. It also helps to anticipate when compatibility shims will be removed. It’s not a pure form of SemVer as each 8 month feature release will continue to have a few documented backwards incompatibilities where a deprecation path isn’t possible or not worth the cost. Also deprecations from each LTS release will be dropped in a non-dot-zero release to accommodate our policy of keeping deprecation shims for at least 2 releases.

Here’s an overview of when deprecated features will be dropped in Django going forward:

  • 1.8 - April 2015 (LTS): Dropped deprecation shims added in 1.6.
  • 1.9 - Dec. 2015: Drop deprecation shims added in 1.7.
  • 1.10 - Aug. 2016: Drop deprecation shims added in 1.8. This still allows running code that was deprecation-warning free on 1.8; the shims dropped are for supporting older unsupported versions.
  • 1.11 - April 2017 (LTS): No deprecation shims dropped. The 1.9 deprecation shims are needed to help apps maintain compatibility back to 1.8 LTS.
  • 2.0 - Dec. 2017: Drop deprecation shims added in 1.9 and 1.10. Apps may drop support for Django 1.8, 1.9, and 1.10 -- 1.8 support will end in April 2018, approximately 4 months after the release of 2.0, and the other two versions are now unsupported.
  • 2.1 - Aug. 2018: Drop deprecation shims added in 1.11. This still allows running code that was deprecation-warning free on 1.11; the shims dropped are for supporting older unsupported versions.
  • 2.2 - April 2019 (LTS): No deprecation shims dropped. The 2.0 deprecation shims are needed to help apps maintain compatibility back to 1.11 LTS.

Future versions: 3.0, 3.1, 3.2 (LTS), 4.0, etc.

Following Django 1.11, the version will be bumped to Django 2.0. After that, each version following an LTS will bump to the next “dot zero” version. LTS versions will always be “X.2” and so third-party apps can target support for X.2 to X+1.2. We aren’t bumping Django 1.9 to 2.0 because Django 1.9 has already been anticipated in the docs and deprecation warnings, so such a change is likely to cause more confusion than it’s worth. django.utils.deprecation.RemovedInDjango20Warning in Django 1.8 will be renamed to RemovedInDjango110Warning in the next patch release (1.8.3), and the documentation has been updated to reflect these changes.

As a final heads up, Django 1.11 is likely to be the last version to support Python 2.7 as it will be supported until the end of Python 2 upstream support in 2020. We’ve adopted a Python version support policy as follows:

We will support a Python version up to and including the first Django LTS release whose security support ends after security support for that version of Python ends. For example, Python 3.3 security support ends September 2017 and Django 1.8 LTS security support ends April 2018. Therefore Django 1.8 is the last version to support Python 3.3.

Frequently Asked Questions and Complaints

Q: Will a time-based release compromise the stability of releases? Why not release when things are ready?

A: Release stability will be a continued priority. Releases will be delayed (and thus support for older versions extended) as necessary if there are major, unsolved issues. Thanks in part to the resources provided by the Django Fellowship program, Django 1.8 was released according to schedule.

C: Stop breaking backwards compatibility. Many hours are wasted and money spent all over the world because of this lack of respect for your users.

A: The team takes backwards compatibility seriously. Sometimes it’s necessary to make such changes to continue the long-term improvement of Django. You can help keep us honest by testing and giving feedback on prereleases. If you value stability over new features, the new deprecation policy should make it easier to use only LTS releases and upgrade less frequently.

C: It's great to see features roll out quickly, with one caveat: I'm starting to see third party packages struggle to both keep up and support the LTS packages.

A: Hopefully the new deprecation policy outlined above will help address this.

Q: Why doesn’t the documentation/release notes include an upgrade guide/checklist for porting from past two or three versions (e.g. upgrade LTS to LTS)?

A: The team suggests upgrading one Django version at a time when you decide to upgrade LTS to LTS. We don't believe we can offer an official LTS-to-LTS upgrade guide (maintaining one is simply too much work and would mostly involve copying the release notes from all the intermediate versions). However, the new deprecation policy will make LTS to LTS upgrades easier, as it won’t require dealing with any API removals (as long as your code does not trigger any deprecation warnings on the older LTS version).

C: It would be good if there were more overlap between LTS releases. Right now we have 6 months between the release of the new LTS before the old LTS is EOLed. This makes it very hard for a product company such as ours, where we have to maintain support for a previous release much longer than those 6 months.

A: The new schedule gives one year of LTS support overlap.

C: 3 years is NOT LTS at all, in the enterprise world LTS means 10 years. I would like to have a very stable Django core that updates only on security problems and important fixes that is supported for minimum of five years.

A: With the exception of the Django fellow, the team is composed entirely of volunteers with limited time. Some of us work in large enterprises, so we are aware of these challenges. We believe that if you need support longer than 3 years, you should consider engaging a paid contractor to patch security issues in your Django installation (much the same way that organizations provide similar support for Python).

Q: I’m the maintainer of a reusable application. Which Django versions should I support?

A: We recommend that you support the same Django versions that are supported by the Django team. With the new deprecation policy, it should be possible to support two consecutive LTS releases (e.g. 1.8 and 1.11) and all the non-LTS versions in between without requiring backwards-compatibility shims in your own code, as long as your code runs warning-clean on the lower LTS (1.8), because any non-deprecated feature in one LTS release is guaranteed to remain in place through the next LTS release.

June 19 2015

Django core team adds two members

The Django core team is thrilled to announce the addition of Tomek Paczkowski and Preston Timmons.

Tomek has been active in the Django community for many years. He has organized many sprints, helped organize DjangoCon Europe 2013, mentored at many Django Girls events, and helped with the djangoproject.com redesign effort. Originally from Poland, Tomek currently lives in London, where he works at Squirrel.

Preston is a software developer with a background in mathematics. He has been contributing code to Django since at least 2010. He has contributed in many areas, notably including the discovery test runner and the Django template language.

We are very grateful for all of Tomek and Preston's contributions, and look forward to working with them on the Django core team.

June 17 2015

Django Software Foundation announces Diversity Statement

While the Django Software Foundation (DSF) has passed a Community Code of Conduct that indirectly establishes that we consider diversity to be a desirable goal, and the DSF has funded many activities that promote diversity, we've never made a clear public statement that we consider diversity a desirable goal.

We'd like to address that.

The membership of the Django Software Foundation has just drafted, and the DSF Board has approved, a Diversity Statement for the Django community. The draft draws heavily on the diversity statement published by Dreamwidth.

These words, by themselves, won't change much about the way the DSF operates. However, The Zen of Python tells us that "explicit is better than implicit". Making a statement like this is a signal to the broader community about what sort of community Django aspires to be -- and if we ever fail to meet those aspirations, we can be called on it so that we can do better.

If you have any questions about this statement, or any other feedback for the DSF, please get in touch.

UPDATE 20 June 2015: Corrected reference to PEP20, rather than PEP8.

May 23 2015

DjangoCon US Registration is open!

Registration is open! You may book your tickets and reserve your hotel accommodations for DjangoCon US!

We've worked hard to lower ticket prices this year, and thus have low prices for students and individuals. Financial assistance is also available to those with limited budgets.

Register for Djangocon 2015 here.

Reserve your hotel accommodation to take advantage of our discounted room rates. This year the daily room rate for single or double occupancy is $139. Please use the reservation code of DJANGO0915.

Applications for Django Girls at DjangoCon (as a coach or as a participant) will be handled separately; please visit Django Girls Austin for information about attending or coaching at the workshop.

For more information see our registration page.

May 20 2015

Security release issued: 1.8.2

In accordance with our security release policy, the Django team is issuing Django 1.8.2. This release is now available on PyPI and our download page. This release addresses a security issue detailed below. We encourage all users of Django to upgrade as soon as possible. The Django master branch has also been updated.

CVE-2015-3982 - Fixed session flushing in the cached_db backend

A change to session.flush() in the cached_db session backend in Django 1.8 mistakenly sets the session key to an empty string rather than None. An empty string is treated as a valid session key and the session cookie is set accordingly. Any users with an empty string in their session cookie will use the same session store. session.flush() is called by django.contrib.auth.logout() and, more seriously, by django.contrib.auth.login() when a user switches accounts. If a user is logged in and logs in again to a different account (without logging out) the session is flushed to avoid reuse. After the session is flushed (and its session key becomes '') the account details are set on the session and the session is saved. Any users with an empty string in their session cookie will now be logged into that account.

Thanks to Sam Cooke for reporting the issue.

Affected versions

  • Django master development branch
  • Django 1.8


Patches have been applied to Django's master development branch and to the 1.8 release branch. The patches may be obtained directly from the following changesets:

The following new release has been issued:

The PGP key ID used for this release is Tim Graham: 1E8ABDC773EDE252.

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.

May 19 2015

Interested in organizing DjangoCon Europe 2016?

DjangoCon Europe 2015 is just a few short weeks away - but we need to start planning for next year!

Each DjangoCon Europe event is run by a different volunteer organizing committee. That committee takes full financial responsibility for all aspects of the event: booking venues and catering, organizing any insurance that is required, finding speakers and sponsors, selling tickets and organizing swag. This usually involves the creation of a not-for-profit organization in the host country. Any profits from the event go back to that host organization to fund future Django activities in the host city.

The host city for DjangoCon Europe 2016 will hopefully be chosen and announced at this year's event. Anyone interested in hosting will be asked to make their pitch to a panel made up of past DjangoCon Europe organizers at this year's DjangoCon Europe. Based on those pitches, the panel will select the host for next year, and the Django Software Foundation will license the use of the "DjangoCon Europe 2016" name to that group.

At this time, we're looking for expressions of interest for hosting DjangoCon Europe 2016. If you're interested in hosting, you should also do some initial research so you're in a good position to pitch. The ideal pitch would be able to provide the following:

  • Key staff. Ideally, it won't be just yourself, but a core team of of 3-5 people who are willing to commit to the event. Past experience organising an event the size of DjangoCon Europe would be well regarded, but is not required.
  • Initial scoping of venues. We don't want to you sign contracts, but it would be good to have a short list in mind, know that those venues are available, have capacity, and are appropriately priced.
  • Indicative numbers on costs associated with flights, accommodation, food etc - i.e., what's the "all included" price likely to be for an attendee.
  • General information about the host city, any why it's an attractive venue.
  • Any grand ideas you have for how to make your event spectacular.

If you're not in a position to provide all this information, that's fine - but the more you can provide, the better the chances for your pitch. At this point, none of the data you present would be "locked in" - we're not asking for final budgets, just evidence that you've done some initial research, have a realistic expectation of how much work is involved, and have a team that can make the event happen.

If you are interested in taking on the task of organizing DjangoCon Europe 2016, or if you'd like more information, please get in touch.

May 07 2015

Django Developers Community Survey

We're conducting a twenty question survey to assess how the community feels about the Django development process.

Please take ten minutes or so to complete it. Your feedback will help guide where we should focus our efforts going forward.

Thanks to the many people who gave feedback on early drafts of the survey.

May 05 2015

Apply for financial aid for DjangoCon US 2015!

We are thrilled to announce that we will be supporting individuals who need financial assistance to attend DjangoCon US 2015.

We’ve pledged $5,000 for the attendees of DjangoCon US 2015 to help meet the cost of tickets, travel, and accommodation for attendees who need financial support.

Our grants committee can supply discounted or free conference tickets and travel assistance. If you are a member of an under-represented group who will not be able to attend DjangoCon US without financial help, we strongly encourage you to apply for financial aid.

You can apply for financial aid by filling out this application. Applications need to be submitted by June 1 in order to be considered (potential speakers should apply by 5/15).

The Django Software Foundation’s grants committee, along with a representative from DEFNA (Django Events Foundation North America), will review financial aid applications and notify those who have been accepted by June 15. Preference will be given to potential speakers and tutorial leaders, especially first-time speakers, and members of under-represented groups.

More information is available on the DjangoCon US 2015 website.

May 01 2015

Bugfix releases issued: 1.8.1 and 1.7.8

Today we're issuing bugfix releases in the 1.8 and 1.7 release series.

Details can be found in the release notes:

The release packages and checksums are available from our downloads page, as well as from the Python Package Index. The PGP key ID used for this release is Tim Graham: 1E8ABDC773EDE252.

April 29 2015

A birthday party for Django

It's hard to believe, but Django was released nearly ten years ago -- here's the very first entry on this blog, which was published in July of 2005.

Ten years is a big milestone, so we're throwing a birthday party in the town where Django was created, Lawrence, Kansas.

The party will be July 10th-12th, 2015. We'll have great food, a great lineup of speakers on Saturday, and a big birthday party Saturday night. We'll be announcing more details soon -- who's speaking, what the party's all about -- but trust me: it's going to be awesome.

Tickets are available now, and are only $90. They won't last long, so if you want one, move quickly.

More information is available on the website, including more about the schedule, our call for speakers, a travel guide, and more.

I hope to see you there!

Django 1.8 release shirt

Last year, to commemorate the release of Django 1.7, we ran a fundraising campaign selling t-shirts and hoodies with a limited edition, specially commissioned design. That campaign raised almost $10,000 for the Django Software Foundation.

Since it was such a great success, we're doing it again for the Django 1.8 release! We've commissioned some new artwork from Django Girls alumni Beatrix Bodó; we're offering that design in 4 styles:

  • a Men's/Unixsex T-shirt ($20),
  • a Women's fitted T-shirt ($20), or
  • a Women's V-neck T-shirt ($20), or
  • a Hoodie ($25).

All profits from the campaign go to the Django Software Foundation, to help fund activities like sprints, travel grants to DjangoCon, and supporting events like Django Girls workshops.

It's a crowdfunding campaign - we need to hit a minimum of 100 sales to confirm the print run. If we don't hit that target, there won't be any shirts! It also means that there's a time limit - you need to place your order by May 12. If you don't place an order before then, you'll miss out!

So - place your orders, and spread the word!

April 21 2015

Security Advisory: Arbitrary file inclusion through docutils

The docutils package is the standard package to render reStructuredText (reST). One of reST’s features is including other files in a document. The respective directives are active by default which is a valid case for the original use case of docutils: rendering documentation.

Django ≤ 1.5 has a package contrib.markup which relies on docutils and provides a template filter that is used to render reST to HTML on demand. This happens without deactivating the problematic directives to include files from the file system. If docutils’ rendering is used with unsanitized user input and without disabling the directives, an attacker can access arbitrary files on the host (at least, the files that the user running the WSGI container can access). This could eventually lead to disclosure of secure information, such as the project settings. This scenario has been documented.

In Django 1.6 the contrib.markup app was removed. However, many third-party applications in the Djangoverse still rely on docutils and also copied the pattern Django uses to allow deactivating the directives:

docutils_settings = getattr(settings, 'RESTRUCTUREDTEXT_FILTER_SETTINGS', {})
parts = publish_parts(
return force_text(parts["fragment"])

These packages may not contain the same warnings that Django's documentation includes, and in any case, it's a good idea to disable file inclusion by default in order to make things "secure by default" rather than relying on users disabling it explicitly.

In order to solve the arbitrary file inclusion package maintainers should adapt to the following pattern:

docutils_settings = {
    'raw_enabled': False,
    'file_insertion_enabled': False,
docutils_settings.update(getattr(settings, 'RESTRUCTUREDTEXT_FILTER_SETTINGS', {}))
parts = publish_parts(
return force_text(parts["fragment"])

Users of packages that use the above pattern should update their project settings to include:

    'raw_enabled': False,
    'file_insertion_enabled': False,

April 03 2015

DjangoCon US 2015 Call for Proposals

We are pleased to announce that DjangoCon US 2015 will take place in Austin, Texas from September 6-11, 2015, marking the eighth year for this gathering of Django developers and enthusiasts.

The Call for Proposals is now open, and closes on May 15, 2015. As with past years, there will be a travel grants program to assist people with financial need. The application process for this grants program will be announced shortly. The deadline for submissions is the end of May 15th.

If you're interested in sponsoring the event, or in helping out with organization, please get in touch.

Start working on those proposals, and we hope we'll see you at DjangoCon US!

April 01 2015

Django 1.8 released

After more than a year of development, the Django team is happy to announce the release of Django 1.8 according to schedule.

This version has been designated as a long-term support (LTS) release, which means that security and data loss fixes will be applied for at least the next three years.

As always, the release notes cover everything in-depth, but some of the major highlights are:

You can get Django 1.8 from our downloads page or from the Python Package Index. The PGP key ID used for this release is Tim Graham: 1E8ABDC773EDE252.

With the release of Django 1.8, Django 1.6 has reached end-of-life. As such, Django 1.6.11 is the final release of the 1.6 series. Django 1.7 will continue to receive security updates until the release of Django 1.9 (planned for October 2015). Django 1.4 (the previous LTS) will receive security updates for another six months (ending October 1, 2015) to give time for users to upgrade to Django 1.8 LTS.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...