2 ms·

Is it an overstatement? Python is handling every bit of IO in your application. You're at the mercy of the implementation to handle it safely. You're talking a

Is it an overstatement? Python is handling every bit of IO in your application. You're at the mercy of the implementation to handle it safely. You're talking about the odds as if nothing has ever been found wrong in the stock CPython interpreter. It's certainly low traffic compared to something like a browser, but there's plenty of bad stuff[1]. That suggests it's pretty likely there will be more after the 2020 deadline, they just won't get a fix. I'm also not sure why you're slinging around IT practice (a month is extraordinary, IMO, but CI testing updates is industry standard around here). What's wrong with good backups? [1]: https://www.cvedetails.com/product/18230/ https://www.cvedetails.com/product/18230/

Silhouette 9y ago
Python is handling every bit of IO in your application. You're at the mercy of the implementation to handle it safely. Sure, but that's true of any programming you ever do in any language. It's certainly low traffic compared to something like a browser, but there's plenty of bad stuff[1]. Would any of those vulnerabilities be a concern if you're using Python for local scripting and automation needs or the like, though? Obviously if you're running untrusted code or processing data from external and potentially hostile sources then you may have a different risk assessment, but Python is used for far more than just things like writing the back ends for web apps. I'm also not sure why you're slinging around IT practice (a month is extraordinary, IMO, but CI testing updates is industry standard around here). What's wrong with good backups? My point was that many organisations already defer installing updates in far more vulnerable areas, such as their Windows machines, for up to a month (because Microsoft chooses to bundle them into monthly patch releases barring the occasional very serious exception) and then typically larger organisations will test out each update in a lab before deploying it more widely, causing further delay. In the meantime, that's a month or more that every machine on the network is potentially vulnerable to whatever exploits might be out there that the patch will eventually prevent. This is standard practice in Windows-based environments, and yet the risk involved is surely far higher than anyone exploiting the Python executable you've kept installed because you have a decade of useful Python 2 scripts around and don't feel like rewriting them all because someone declared Python 2 was dead. Likewise, a large organisation getting hit by ransomware can obviously be crippling and the best defence is having back-ups as recent as possible so you can immediately restore any encrypted data. And yet, again, most organisations don't have that sort of infrastructure in place, and again, this is surely a much greater risk than having Python 2 around to run all your old Python 2 scripts.
- oliwarner 9y ago
  I will cede that there are non-hostile areas where Python 2 could run forever. The same sort of environments where FORTRAN have rumbled on forever. And I agree that there are other hostile environments where some organisations have completely the wrong priorities. Desktops and networks and traffic management rarely seem to be perfect. But on Python, I think many people underappreciate the attack surface. Just because it's not a server doesn't mean you can't feed it a malformed JPEG, or funky bytestring that causes it to blow up and spawn shells. It's a similar problem to PHP in that python includes so many batteries, it's trivial for attackers to branch out. And much of this frustration —which leads to the strength of language— is that we bump into clients and clients' developers who proudly announce they're running a stack 4 years out of date. It's stupid the number of times I've had to explain why this is a bad idea. I've even had to demonstrate deep hacks (with permission, and remuneration) to clients who think they're immune "because Linux" or whatever. Basically they didn't want to pay their technical debt until they can see a 12yo Ukrainian (not important) kid could destroy their whole company.

Silhouette 9y ago

Python is handling every bit of IO in your application. You're at the mercy of the implementation to handle it safely. Sure, but that's true of any programming you ever do in any language. It's certainly low traffic compared to something like a browser, but there's plenty of bad stuff[1]. Would any of those vulnerabilities be a concern if you're using Python for local scripting and automation needs or the like, though? Obviously if you're running untrusted code or processing data from external and potentially hostile sources then you may have a different risk assessment, but Python is used for far more than just things like writing the back ends for web apps. I'm also not sure why you're slinging around IT practice (a month is extraordinary, IMO, but CI testing updates is industry standard around here). What's wrong with good backups? My point was that many organisations already defer installing updates in far more vulnerable areas, such as their Windows machines, for up to a month (because Microsoft chooses to bundle them into monthly patch releases barring the occasional very serious exception) and then typically larger organisations will test out each update in a lab before deploying it more widely, causing further delay. In the meantime, that's a month or more that every machine on the network is potentially vulnerable to whatever exploits might be out there that the patch will eventually prevent. This is standard practice in Windows-based environments, and yet the risk involved is surely far higher than anyone exploiting the Python executable you've kept installed because you have a decade of useful Python 2 scripts around and don't feel like rewriting them all because someone declared Python 2 was dead. Likewise, a large organisation getting hit by ransomware can obviously be crippling and the best defence is having back-ups as recent as possible so you can immediately restore any encrypted data. And yet, again, most organisations don't have that sort of infrastructure in place, and again, this is surely a much greater risk than having Python 2 around to run all your old Python 2 scripts.

oliwarner 9y ago
I will cede that there are non-hostile areas where Python 2 could run forever. The same sort of environments where FORTRAN have rumbled on forever. And I agree that there are other hostile environments where some organisations have completely the wrong priorities. Desktops and networks and traffic management rarely seem to be perfect. But on Python, I think many people underappreciate the attack surface. Just because it's not a server doesn't mean you can't feed it a malformed JPEG, or funky bytestring that causes it to blow up and spawn shells. It's a similar problem to PHP in that python includes so many batteries, it's trivial for attackers to branch out. And much of this frustration —which leads to the strength of language— is that we bump into clients and clients' developers who proudly announce they're running a stack 4 years out of date. It's stupid the number of times I've had to explain why this is a bad idea. I've even had to demonstrate deep hacks (with permission, and remuneration) to clients who think they're immune "because Linux" or whatever. Basically they didn't want to pay their technical debt until they can see a 12yo Ukrainian (not important) kid could destroy their whole company.