Maybe ... some effort to solve the infrastructure issue would make it
worth kickstarter funding.
Python 3.4 environment but that is beyond my interest atm.
less forces me to stick with Python 2.7. I would like to move to Python
3.x using virtualenv but I don't want to mess with stuff which is working.
approach would be covered by standard Ubuntu support. I have only
glanced at Docker so I don't know how valid that might be.
Just a random thought.
Post by Christian Hammond
I can definitely relate. It's not fun maintaining security releases (or
fixes of any sort) for older versions of the software. Been there (am
We're trying to encourage people to move to Python 2.7 so that we can
upgrade, but this is the enterprise. It's not an easy task. (Look how
long Microsoft tried to get people off of IE6.) Python 2.6 is still
wildly populate in the enterprise. The sad fact is, even once we leave
Python 2.6 behind, there's going to be at least a few hundred companies
with servers running Django 1.6.x who will not be upgrading for quite
some time, no matter what any of us do or say (just as there are still
at least a hundred running against Django 1.4). Once security releases
stop for 1.6, these companies are going to be vulnerable to any new
I wholeheartedly agree about using virtualenv and staying on top of the
latest releases, but we've had little luck in getting administrators to
move in that direction. We've been trying to work with a handful
recently who insist on running older versions with very custom
deployments because "it works and we don't want to risk anything," but
at the same time they're quick to pull in any security updates offered
by RHEL/us/whoever, as it's a liability otherwise. Especially since, as
others have said, they have support contracts in place that they're
paying a lot of money for, and will not violate. The advice on
virtualenvs and building your own Python is good, and I appreciate it
and agree with it, but it just won't make a dent in the number of
enterprise Python 2.6/Django 1.6 users out there.
So... we're in a tough position now. Hundreds of companies *will* be on
Django 1.6 for the next couple of years at least, no matter what advice
we give or what any of us choose to do. Since newer versions of Django
don't support Python 2.6, it'll be even harder for these companies to
upgrade without rebuilding their infrastructure, further ensuring that
they'll stick with what they have.
I wish I could say that we could fully-fund future Django 1.6 security
updates, but our company is young and still trying to stay afloat, so
our funds are limited. I'll personally contribute what I can afford to
the cause, if I knew what sort of target there was, and how likely this
would be to happen. I don't want to leave our users hanging and vulnerable.
The only other course of action I can think of is to maintain some sort
of unofficial fork of Django 1.6 with backported security updates, but I
think that's just going to cause more problems than it solves in far too
Maybe I'm rambling at this point. It's a pretty major issue for us, and
we're feeling a bit stuck on what to do about this. Since we use Django
as a component in a distributable webapp, instead of in-house in a
controlled environment, we seem to hit problems that most people don't
have to deal with.
Thanks again for your thoughts on this, everyone.
Having managed the last few security releases for Django, I'll say
it's one of my least favorite tasks and I'm quite looking forward to
dropping support for 1.4 (which supports Python 2.5) and 1.6 (Python
2.6). But, if there's sufficient interest that we could raise funds
to support this effort outside of my normal duties as Django fellow,
there's a chance you could convince me to continue backporting
patches and preparing releases for these versions. I'm not quite
sure how the logistics of such an arrangement would work, but just
thought I'd throw the idea out there and see if anyone is ready to
back the effort financially. I'd want the endorsement of the core
team before finalizing anything.
It certainly sounds like there's an opportunity here for someone to
provide extra-extended security-backport support for certain Django
releases (beyond the ~3.5 years we'll typically support an
under current policy), to accommodate these enterprise users
on dead (to
upstream) Python versions.
I remain quite unconvinced that this "someone" should be the
team. I think the core team's limited energies are better spent
continuing to move Django forward.
Sure, I both understand and respect that. The problem is that it
moves the problem further up the stack and closer to the end-users.
The platform vendor (Red Hat, SUSE, etc.) won't take on the
responsibility for every package, or likely any package that
doesn't directly support something they are trying to sell to a
customer. Hence why the major vendors don't ship a copy for
The community-supported add-ons are all volunteer efforts, most
often by amateur packagers who are only in rare occasions
equipped to do real engineering work to backport patches. These
people rely on the upstreams continuing to support the packages
so they can package the updated releases. Sometimes this leads
to an upstream killing off support for a release and the add-on
repository being unable to upgrade. This is bad for everyone,
because over time this *will* (not may) end up with packages in
the wild with known vulnerabilities and little-to-no way to address it.
So the responsibility then goes to the framework developers who
have more engineering knowledge about the subject but generally
fewer resources to spare. So the answer there is that "someone
else" needs to step up and take over the security maintenance.
Unfortunately, that now brings it up to the application developers.
Application developers rarely know the internals of the packages
they depend on; generally they consume the public API and don't
think twice about the rest of the implementation. Similar to the
framework developers, they have limited resources best spent on
delivering something their customers can use. With a lack of
knowledge of the framework, they're not generally equipped to do
the maintenance themselves. Traditionally, this results in a
functional equivalent to the worst-case of the add-on repository
situation above: application developers just bundle a version of
the framework that worked when they implemented it and *never
update it*. This inevitably ends with something that appears to
work for their users but will eventually bit-rot and become a
Lastly, we have the application users. Let's be honest: do we
want end-users responsible for maintaining the complete stack?
They're going to do what they always do: find and install one
version (no matter how old) and just use it until something goes
wrong, at which point they have no one to call who knows the
system and can fix it for them.
When looking at the big picture, the best thing for end-users is
for the lowest levels of this stack to take control of
maintenance for it. In cases where the stack is critical
infrastructure (like the Python interpreter itself), the OS
vendor will take it over, even to the degree of maintaining it
past its upstream end-of-life. Where it's not critical
infrastructure, the upstream developers are the best-equipped to
manage maintenance. Further up in the stack than that, you have
a very unbalanced scale of decreasing knowledge vs increasing
need for stability.
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.