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. 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/aa815ee5-b0d0-47b2-bdd6-824c9209f356%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
