Maybe ... some effort to solve the infrastructure issue would make it
worth kickstarter funding.
A couple of colleagues are pushing me towards Docker as a packaged
Python 3.4 environment but that is beyond my interest atm.
I am running a dedicated production server on Ubuntu 14.04 which more or
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.
Maybe a really nice solution would be a kickstarter project to develop a
deployment tool to create a predictable, supportable modern environment
on "old" boxes and to vaccuum up the existing Django sites running on
bare metal.
In my case, Ubuntu does support Python 3.4 (I think) so the virtualenv
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.
Mike
On 19/03/2015 1:38 PM, Christian Hammond wrote:
Hey Tim,
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
there now).
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
exploits.
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
many areas.
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.
Christian
On Wednesday, March 11, 2015 at 6:54:51 PM UTC-7, Tim Graham wrote:
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.
On Wednesday, March 11, 2015 at 12:49:55 PM UTC-4, Stephen Gallagher
wrote:
On Wednesday, March 11, 2015 at 12:00:25 PM UTC-4, Carl Meyer wrote:
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
LTS release
under current policy), to accommodate these enterprise users
on dead (to
upstream) Python versions.
I remain quite unconvinced that this "someone" should be the
Django core
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
themselves.
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
liability.
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
an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/aa815ee5-b0d0-47b2-bdd6-824c9209f356%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/aa815ee5-b0d0-47b2-bdd6-824c9209f356%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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 an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/550A6C65.9040303%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
