4 ms·

Debian should not ship broken software. They would need to test Python2 and make sure it works. As the environment grows increasingly divergent from what was su

Debian should not ship broken software. They would need to test Python2 and make sure it works. As the environment grows increasingly divergent from what was supported in Python2's time this will become an increasing burden. Debian does not plan to maintain support for unversioned python commmands [1]. As much Python2 software assumes this is the case, continuing to provide these packages would become an ongoing burden. Python2 has not had a security update since the EOL version 2.7.18. I am not aware of any current CVE's against this version but if one were found Debian would either have to withdraw the package or patch it for any stable versions of Debian. This includes maintaining the build infrastructure for Python2 to be able to patch it if required, bug tracker, etc. as long as Python2 is offered. > What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023. I do not have numbers for this, but as the commercial Python2 support I was looking at (Activestate) is "inquire for pricing" I would imagine the equivalent community manpower/resource cost is significant. Just hosting the .deb in the APT repos is cheap - everything else around it is the expensive part. So it is not so much "the cost of removing it" and more "the cost of keeping it around". [1] https://www.debian.org/doc/packaging-manuals/python-policy/index.html#unversioned-python-commands https://www.debian.org/doc/packaging-manuals/python-policy/i...

mikewarot 4y ago
So the best option seems to be to avoid any Python dependencies, as this is likely to happen again with Python 4. The idea of having to test a language seems weird, either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it? Also, why does an interpreter need security updates? That's the job of the operating system, not applications, languages, or compilers. You should be able to run any random program in a safe and secure manner, no matter how evil it is. It's the lack of capability based security that is the real problem with Linux.
- waste_monk 4y ago
  >as this is likely to happen again with Python 4 Apparently there will be no Python 4 [1]. >The idea of having to test a language seems weird, either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it? Sorry if this was not clear - not testing the language (although you'd need to make sure the standard library works properly for anything with C bindings), but that the interpreter runs properly under each new version of the Debian operating system. Debian would have to build and package the Python2 binary and related stuff from upstream. There are no Python2 vendor-supplied Linux binaries or deb packages. Officially continuing support would also include having to provide patches in case of security issues etc., fixing any breakage (I'm not sure what Python depends on but I have had friends suffer breakage between versions of Debian with newer versions of glibc and so on), etc. >Also, why does an interpreter need security updates? Things like this issue in Python's sockets library[2]: "Buffer overflow in the socket.recvfrom_into function in Modules/socketmodule.c in Python 2.5 before 2.7.7, 3.x before 3.3.4, and 3.4.x before 3.4rc1 allows remote attackers to execute arbitrary code via a crafted string. " There have been a number of vulns for Python itself over the years [3]. Not aware of any for the last version of Python2 but that may be simply for lack of attention given it's EOL and in theory everyone should have migrated to Python3 by now. >You should be able to run any random program in a safe and secure manner, no matter how evil it is. >It's the lack of capability based security that is the real problem with Linux. Perhaps, and things like SELinux help, but it does not change the reality that someone has to maintain the software when these issues do show up. [1] https://www.techrepublic.com/article/programming-languages-why-python-4-0-will-probably-never-arrive-according-to-its-creator/ https://www.techrepublic.com/article/programming-languages-w... [2] https://www.cvedetails.com/cve/CVE-2014-1912/ https://www.cvedetails.com/cve/CVE-2014-1912/ [3] https://www.cvedetails.com/version-search.php?vendor=Python&product=Python&version=2.7%25 https://www.cvedetails.com/version-search.php?vendor=Python&...
  - mikewarot 4y ago
    >things like SELinux help The problem is that SELinux is not an implementation of capabilities based security, despite appearances.

mikewarot 4y ago

So the best option seems to be to avoid any Python dependencies, as this is likely to happen again with Python 4. The idea of having to test a language seems weird, either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it? Also, why does an interpreter need security updates? That's the job of the operating system, not applications, languages, or compilers. You should be able to run any random program in a safe and secure manner, no matter how evil it is. It's the lack of capability based security that is the real problem with Linux.

waste_monk 4y ago
>as this is likely to happen again with Python 4 Apparently there will be no Python 4 [1]. >The idea of having to test a language seems weird, either the interpreter runs, or it doesn't. Why should the Linux Distribution have their fingers in it? Sorry if this was not clear - not testing the language (although you'd need to make sure the standard library works properly for anything with C bindings), but that the interpreter runs properly under each new version of the Debian operating system. Debian would have to build and package the Python2 binary and related stuff from upstream. There are no Python2 vendor-supplied Linux binaries or deb packages. Officially continuing support would also include having to provide patches in case of security issues etc., fixing any breakage (I'm not sure what Python depends on but I have had friends suffer breakage between versions of Debian with newer versions of glibc and so on), etc. >Also, why does an interpreter need security updates? Things like this issue in Python's sockets library[2]: "Buffer overflow in the socket.recvfrom_into function in Modules/socketmodule.c in Python 2.5 before 2.7.7, 3.x before 3.3.4, and 3.4.x before 3.4rc1 allows remote attackers to execute arbitrary code via a crafted string. " There have been a number of vulns for Python itself over the years [3]. Not aware of any for the last version of Python2 but that may be simply for lack of attention given it's EOL and in theory everyone should have migrated to Python3 by now. >You should be able to run any random program in a safe and secure manner, no matter how evil it is. >It's the lack of capability based security that is the real problem with Linux. Perhaps, and things like SELinux help, but it does not change the reality that someone has to maintain the software when these issues do show up. [1] https://www.techrepublic.com/article/programming-languages-why-python-4-0-will-probably-never-arrive-according-to-its-creator/ https://www.techrepublic.com/article/programming-languages-w... [2] https://www.cvedetails.com/cve/CVE-2014-1912/ https://www.cvedetails.com/cve/CVE-2014-1912/ [3] https://www.cvedetails.com/version-search.php?vendor=Python&product=Python&version=2.7%25 https://www.cvedetails.com/version-search.php?vendor=Python&...
- mikewarot 4y ago
  >things like SELinux help The problem is that SELinux is not an implementation of capabilities based security, despite appearances.