4 ms·

>For me, and my camp, it seems silly to simply write off all the code that conformed to the standards of the time, and doesn't properly bow to the changing fash

>For me, and my camp, it seems silly to simply write off all the code that conformed to the standards of the time, and doesn't properly bow to the changing fashions of the day. It is not about fashion, it is about resources and manpower. Supporting Python2 is not free, especially post-EOL, and a huge amount of community effort has gone into supporting it. It is not fair to demand that Debian ensure that vendor-unsupported legacy software continue working indefinitely, especially given the environment it would be running on is a moving target that will only diverge further from what was contemporary with Python2 with each release. >This isn't like a web site where there is an active party supporting the other end This is exactly like that. The "active party" in this case just happens to be the Debian community. If you wish to continue using Python2, either stick to running it on an outdated environment such as Debian Buster that supports it natively (and accept the security consequences of doing so), take on the burden of porting it to modern Debian yourself, or seek out one of the commercial support options that exist for post-EOL Python2. You are not entitled to indefinite free labour.

mikewarot 4y ago
What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023. I don't understand why the Python community doesn't just run python2 syntax with a flag, similar to the std=c89 flag in gcc.
- waste_monk 4y ago
  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

What's the actual cost of not taking Python out of the repositories? I can still run Windows 32 bit applications in 2023. I don't understand why the Python community doesn't just run python2 syntax with a flag, similar to the std=c89 flag in gcc.

waste_monk 4y ago
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&...