Re: Django 1.3 and extensions.gnome.org

["Jasper St. Pierre" <jstpierre mecheye net>]

On Thu, Oct 13, 2011 at 3:53 PM, Jeff Schroeder
<jeffschroeder computer org> wrote:
> On Thu, Oct 13, 2011 at 12:45 PM, Owen Taylor <otaylor redhat com> wrote:
>> So, extensions.gnome.org is written as a Django application. And i
>> particular it's written against Django-1.3, which is the issue here.
>> It's not very hard for us to build a local version of Django and put it
>> in the gnome package repositories, but this brings up issues.
>>
>> Compatibility
>> =============
>> We have (I think) three current apps using Django:
>>
>>  tomboy-online.org (snowy): Runs on on Django-1.2.6 on RHEL6, the code
>>  also has been tested on Django-1.3 and works.
>>
>>  shell-perf.gnome.org: small, unimportant, currently running on
>>  Django-1.2.6 on webapps.gnome.org, could presumably be ported to
>>  Django-1.3 without problem
>>
>>  l10n.gnome.org (damned-lies): runs on progress.gnome.org, which is
>>  not part of the main gnome.org cluster and runs Ubuntu 10.4 LTS
>>  with Django-1.1.2
>>
>> As well as a Django version of Mango in development, but not yet
>> deployed.
>
> What about the library.gnome.org and extensions.gnome.org stuff? Isn't
> that in django?

Uh, extensions.gnome.org is what we're talking about here, isn't it?

Also, I tried a very basic effort to port to 1.2 by gluing class-based
views on top of 1.2. It doesn't work: Django has lots of isinstance()
and hasattr() plumbing to make class-based views work. Trying to go
any further ends up in the realm of monkey patching, which effectively
means a non-maintained version of 1.3 in the SweetTooth codebase: even
worse than a custom installation.

At this point, we have two options:

1) Use 1.3

  The simplest solution for now. I don't think security releases are
too common to warrant to a full backport to 1.2, and I've expressed
this opinion to Owen, but he's still unsure.

2) Do a full-on port to 1.2

  This will probably take a week or two at the very least. It's a
one-time cost, sure, but besides losing the obvious 1.3 features, I'm
unsure that the site won't break in various ways. There's just lots of
plumbing that changes between releases. I should have written a lot
more tests.

Most of the security fixes in 1.3.1 are in things that I don't use:
two of the four patches included are for the verify_exists feature for
URLField, which I turn off. Django 1.3 already used the sessions "db"
backend by default, so again, not affected. The only potential attack
is the Host header cache poisoning. I'm unsure of how the webapps are
deployed, but if it's behind a standard nginx proxy or something, it
should be normalizing the Host header it sends to Django.

Yes, I know I'm "missing the point" and that security updates that
affect us could be issued at any point. I'm just reluctant to do a
full backport to 1.2 for what seems to me to be an issue with
deployment.

> --
> Jeff Schroeder
>
> Don't drink and derive, alcohol and analysis don't mix.
> http://www.digitalprognosis.com
>
-- 
  Jasper