UK Cybersecurity Agency Urges Devs To Drop Python 2 (zdnet.com) 50
Python's End-of-Life date is 129 days away, warns the UK National Cyber Security Centre (NCSC). "There will be no more bug fixes, or security updates, from Python's core developers."
An anonymous reader quotes ZDNet: The UK's cyber-security agency warned developers Thursday to consider moving Python 2.x codebases to the newer 3.x branch due to the looming end-of-life of Python 2, scheduled for January 1, 2020... "If you continue to use unsupported modules, you are risking the security of your organisation and data, as vulnerabilities will sooner or later appear which nobody is fixing."
"If you maintain a library that other developers depend on, you may be preventing them from updating to 3," the agency added. "By holding other developers back, you are indirectly and likely unintentionally increasing the security risks of others... If migrating your code base to Python 3 is not possible, another option is to pay a commercial company to support Python 2 for you," the NCSC said.
The agency warns that companies who don't invest in migrating their Python 2.x code might end up in the same position as Equifax or the WannaCry victims. "At the NCSC we are always stressing the importance of patching. It's not always easy, but patching is one of the most fundamental things you can do to secure your technology," the agency said. "The WannaCry ransomware provides a classic example of what can happen if you run unsupported software," it said. "By making the decision to continue using Python 2 past its end of life, you are accepting all the risks that come with using unsupported software, while knowing that a secure version is available."
An anonymous reader quotes ZDNet: The UK's cyber-security agency warned developers Thursday to consider moving Python 2.x codebases to the newer 3.x branch due to the looming end-of-life of Python 2, scheduled for January 1, 2020... "If you continue to use unsupported modules, you are risking the security of your organisation and data, as vulnerabilities will sooner or later appear which nobody is fixing."
"If you maintain a library that other developers depend on, you may be preventing them from updating to 3," the agency added. "By holding other developers back, you are indirectly and likely unintentionally increasing the security risks of others... If migrating your code base to Python 3 is not possible, another option is to pay a commercial company to support Python 2 for you," the NCSC said.
The agency warns that companies who don't invest in migrating their Python 2.x code might end up in the same position as Equifax or the WannaCry victims. "At the NCSC we are always stressing the importance of patching. It's not always easy, but patching is one of the most fundamental things you can do to secure your technology," the agency said. "The WannaCry ransomware provides a classic example of what can happen if you run unsupported software," it said. "By making the decision to continue using Python 2 past its end of life, you are accepting all the risks that come with using unsupported software, while knowing that a secure version is available."
It just means (Score:3)
not gonna happen... (Score:5, Informative)
Re:not gonna happen... (Score:5, Informative)
Moving from 2 to 3 can be a real nightmare
My company switched years ago, and didn't have any significant problems.
Pylint [pylint.org] was very useful for finding portability problems, so we cleaned those up before the switch.
What upgrade problems are you having?
Re: (Score:3, Informative)
Re: not gonna happen... (Score:2)
Some examples would be nice.
Re: (Score:3)
Re: (Score:2)
wxWhatever has always had that problem.
I experienced that in 2000 using Perl, and went back to Gtk. You can still use Gtk today, too. Even the old versions.
Re: (Score:2)
wxPython supports Python3 now.
The situation with Python 2 vs 3 libraries has changed dramatically in the last few years. http://py3readiness.org/ [py3readiness.org]
Re: (Score:2)
Re: not gonna happen... (Score:3)
Re: (Score:2)
This doesn't match my experience. In one of my past jobs we maintained a Python code base starting with Python 2.2 up to Python 2.6 and I don't recall a single issue we had when upgrading within 2.x.
Migrating it to Python 3.5 of course took some work but we did it incrementally over the course of about 1.5 years. Using middleware like
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Not Likely (Score:2)
I work in VFX, most of our scripting is done in Python 2.
The VFX Reference Platform ( https://vfxplatform.com/ [vfxplatform.com] ) only has Python 3 scheduled to begin use in 2020, and I'm not sure about other software, but the main applications we use, Maya and Max don't even have a beta that uses the 3 interpreter as far as I know.
Re: (Score:2, Informative)
Yes, this transition has not been well thought out, because it is simply trying toi ignore the fact that a lot of libraries, which are the very REASON python is so popular, simply have not transitioned.
Why? There are no doubt many reasons - however of the of the big ones is that Python 3 broken enough of its internals be be damned annoying for library developers to transition, while providing very little in the way of real world advantages to trigger efforts to move.
Adding a 'move because we are forcing you
Re: (Score:1)
Not well thought out? The end-of-life date for Python 2 was announced six years prior, in 2014. Python 3 has been around for a decade. That's about as long a runway as I've ever seen. And what popular packages haven't transitioned to Python 3? See: https://python3wos.appspot.com/
Re: (Score:2)
Yes, it was declared a long time ago - want to point out any consideration about how it is progressing, what reasons there are to remove support for previous versions, how many important libraries have not yet transitioned, etc?
THAT is thought out, not 'we will change in 5 years, hell or high water'.
Re:Not Likely (Score:4, Insightful)
The lack of which popular libraries are holding you back?
It has been over 10 years. I can't name a single major library that was left behind.
> Adding a 'move because we are forcing you to' on top of this is hardly likely to help things.
Python 2.7 was released in July 3rd, 2010. Python had 8 releases since. How much longer do you think it needs to be updated? Especially when it is a free product?
Compared to Perl, Python had a dream transition that was very well planned and extensively discussed as Python 3000 for a very long time before Python 3.0 was released.
Re: (Score:2)
Python 2.7 was released in July 3rd, 2010. Python had 8 releases since. How much longer do you think it needs to be updated? Especially when it is a free product?
Compared to Perl, Python had a dream transition that was very well planned and extensively discussed as Python 3000 for a very long time before Python 3.0 was released.
Compared to C++ or Java, though? I've got code I've never migrated "to" C++11/14/17/2a. There are bits I wrote in 2003, and it wasn't a new codebase then. It's still going. For C++ a
Re: (Score:2)
I work with Java and the migration from Java 6 (the last Sun-developed Java) to Java 7 and then later on Java 8 was not a completely smooth one. It was worth making the jump, but there were quite a few serious issues that arose.
The big thing to keep in mind with Java though is that the JVM bytecode changed between 6 and 7, which would be equivalent to their being substantial microarchitecture changes in C-land...if everyone used a single unified microarchitecture, and everyone was used to releasing librarie
languages unsecure? (Score:2)
Pre.S. Forgive my lack of knowledge but I have no idea how these things work.
How can a prog. language be non-secure?
Is C78 non-secure?
It may be easy to create bugs but it doesn't seem more hackable by a virus or something than C04.
P.S. I don't know of 1978 and 2004 actually have C versions but any old and new versions of a language will work.
Aren't they still making new Fortrans or Cobols or something.
Re: (Score:3)
There could be overflow bugs and crypto libraries could have weaknesses or bugs, and will go obsolete
That said, many distros will be maintaining python 2 until at least 2023, so not seeing why the "panic". I think python zealots just want the world on the version that makes them happy, when most python code doing real work is at python 2... and can stay that way for 3.5 more years at least
Re: (Score:2)
Security issues can stem from bugs in the interpreter, runtime library, and standard library. There's no interpreter for C, but security issues are regularly found in the GNU and Microsoft C runtime libraries. Java virtual machines are no stranger to security vulnerabilities. (On top of that, the language or standard library could have some feature that's specified in a way that's likely to lead to security issues, which can't be fixed without an incompatible change.)
Re: (Score:2)
false alarm, good to 2023+ in many distros (Score:4, Insightful)
long term support distros will have to maintain python 2 until 2023 at least. So why bother?
Re: (Score:2, Insightful)
distros don't write patches for upstream projects unless it's a bug of the actual package. long term support by a distro just means they will continue to release updates but in this case there won't be any updates to release
Re: (Score:2)
distros don't write patches for upstream projects unless it's a bug of the actual package. long term support by a distro just means they will continue to release updates but in this case there won't be any updates to release
That's incorrect, at least for enterprise-quality distributions (and their community rebuilds).
If there's a security issue, RedHat will fix it. Usually this means co-ordinating with upstream, but if upstream is living in la-la land, that doesn't mean RH won't address the security issue for its customers -- that's what you're paying them for.
Re: (Score:2)
If there's a security issue, RedHat will fix it
do you have an actual example of RHEL fixing something in an upstream project that was EOL (and that the one who fixed it wasn't part of the actual upstream project? (since tons of red hat employees actually are part of said projects)
makes little sense. that would be like Microsoft fixing a chrome bug. You are not paying RHEL to fix upstream stuff, you are paying them to make sure they include the patches released by upstream. I mean, i hope you are right but i
Re: (Score:3)
https://access.redhat.com/secu... [redhat.com] gives a perfect example of what Red Hat does. Their example is PHP, with unmaintained older versions which Red Hat still supports (5.3, in the case of RHEL 6, until November 2020).
Re: (Score:3)
They even backport kernel patches, so it is a really basic thing to know if you use RH type stuff.
There isn't some ivory tower, elitist thing about "oh, that is Upstream, we don't do Upstream." I know a lot of the volunteer distros are that way, but RHEL is the pragmatic distro designed for servers and workstations. For business.
That's why I use Centos. For the pragmatism, without the subscription.
Re: (Score:2)
The problem is that RHEL doesn't really support that many Python libraries.
I would suspect it boils down to the stuff that they need to run their distro and the accompanying tools (a large part of support-tools like anaconda (the installer) are written in Python after all).
So, you've still got to backport all the fixes to other modules.
I've got a customer with an app on python2.7. It's very old and they have expressed that they're not going to rewrite it and rather hope to be able to retire it in a couple o
Re: (Score:2)
fixes? if the app is old and has mature test suite it should not need any fixes in python land, the only concern would be security vulnerabilities in things like crypto... which Redhat DOES maintain.
Re: (Score:2)
Generally speaking, libraries in the distro are to support applications in the distro. Something private, like a client's application, shouldn't be coupled to a distro at all, and so shouldn't be using those libraries.
Re: (Score:2)
yes they do and they will, we pay them to do it
so, all you spergs barking like seals every time you see python 2, will just have to keep barking. No reason to change.
Re: (Score:2)
I mean the main reason to bother is so in less than 3.5 years, people aren't running and screaming that their version of Python is about to become unsupported in their current distro :D
Now that I'm in my 40s, 3.5 years doesn't seem like that long - especially if you're talking about a large codebase.
Re: (Score:2)
yeah but the point is that there will be support for years, that's all
Instead python developers and pythoners want everyone to immediately jump on the "ooo shiny" version... which really is another language for many users, in the sense their stuff won't run. Our data analytics stuff at work won't run under 3.0.... and there is no reason it needs to. When we get around to writing the Next Big Thing it can be done in 3, if python the language chosen.
Re: (Score:2)
Because when it does run out of support, your current system will have migrated and be stable?
It's just over 3 years away, which should give people enough time to plan a migration of their core tools and applications to python 3, actually do the migration, and to run the migrated system for enough time to declare it stable and fit for use. While still keeping the old system supported in case major issues happen durin
Worst software transition in history (Score:2)
A number of years back I picked up a project using Python and I greatly enjoyed learning the language and learning to code new stuff in it. I ended up wishing I had learned it a decade sooner there were a lot of places where I could have used it.
Until I got to the Python 2 vs. Python 3 stuff. I never understood how a language upgrade could have been so botched. The much hated (not by me) Java managed to go through almost a dozen fairly major upgrades without creating this kind of chaos. Other langua
Re: (Score:3)
And nothing about Python3 is especially motivating. It fixes some weirdness and inconsistency, but they couldn't do it without breaking code, yet Python2.7 is good enough. Why not just let them go finish their language and migrate when they're done?
Re:Worst software transition in history (Score:5, Informative)
Quick summary is that the Python devs thought it would be better to break backwards compatibility with Python 2, so as to have a "clean" language (unencumbered by awkward/obsolete ways of doing things) going forward with Python 3.
So, the benefit of that is that everything in Python 3 is "correct" (in the sense that a number of baked-in design mistakes discovered only after Python 1's public release were finally ripped out and redone). The drawback is a partial lack of backwards compatibility, requiring every Python program in the universe to be at least partially rewritten.
They decided to incur a lot of short-term developer pain in the hope of realizing a long-term gain in language quality. Regarding whether that was the right decision or not, I won't speculate.
Re: (Score:2)
On other words, Python developers decided to write a new language based on the lessons they learned from Python 2. Rather than naming it something new, they decided to call it a new version of Python. There are scripts out there that translate Python to Perl, it doesn't make Perl a new version of Python.
Re: (Score:1)
Re: (Score:2)
It is a different language , because stuff won't run.
Just as in going from 3.5 to next stuff won't run. So now we have 3 languages.
But meanwhile distros with LTS will be supporting python 2 so no one has to make the python zealots happy by running their other languages. Python zealots lost mindshare, the majority aren't going with their pointless agenda.
Re: (Score:2)
Python 3 is not a new language.
My experience is that you will avoid a lot of frustration and misconceptions if you treat Python2 and Python3 as different languages.
Re: (Score:2)
Re: (Score:2)
Python didn't need to exist in the first place, as we already had Perl, which doesn't break when you copy and paste from a site that destroys whitespace. So why not throw more bad effort at the bad project?
Re: Worst software transition in history (Score:2)
Yup, that's it. They broke the whole universe of libraries. And for WHAT? Python3 is not noticeably better than Python2.
Load of Crap ... (Score:1)
"The WannaCry ransomware provides a classic example of what can happen if you run unsupported software," it said. "By making the decision to continue using Python 2 past its end of life, you are accepting all the risks that come with using unsupported software, while knowing that a secure version is available."
This is a load of crap. Unsupported Software was impervious to WannaCry as it only affected Supported Software. Moreover, the damage was already done by the time the "Supported" or "Unsupported" st