PEP 594 – Removing dead batteries from the standard library • Hacker News Board

Re: PEP 594 – Removing dead batteries from the standard library

#91

Post by mark-r » Tue, Mar 15, 2022, 3:01 PM UTC

waste_monk wrote: post #89

mark-r wrote: post #78

Earlier quoted context omitted.

Windows 7 is the best version of Windows Microsoft ever made, and I won't give it up until I have absolutely no choice. I'm already disappointed that I can't get Python 3.9 - I don't understand why they have to actively bar you from installing it rather than just telling you to use it at your own risk.

Because it prevents whole classes of support issues - if you can't install it, you can't raise a ticket complaining that something doesn't work under 7 and then waste support time... even if you say "if you're running windows 7 you're on your own" people will still try it on, or ask for one little tweak to make things work... all effort that could be better spent on forward progress or real support issues. It is far…

I consider "in the grave" to be a feature. It means Microsoft isn't trying to pull the rug out from under me each night with updates.

Re: PEP 594 – Removing dead batteries from the standard library

#92

Post by skissane » Tue, Mar 15, 2022, 10:52 PM UTC

qbasic_forever wrote: post #33

nrclark wrote: post #32

Earlier quoted context omitted.

You're right, nothing is stopping anybody from putting these modules on Pypi. If somebody's already using Pypi dependencies, then another is no big deal. But there's a really big jump from "This tool is self-contained" to "This tool needs X from pypi". It ripples into deployment, source-control, everything. I try very hard to make tools that don't need anything except for Python's stdlib. That's based on a perception…

cgi, nntp, telnet, etc. are old and obsolete. And not just in the 5 years out of fashion/not the trendy new thing--these things are decades out of date and have major or glaring security issues, etc. If you're publishing brand new code in 2022 that still depends on python's built-in cgi support, etc. you have far greater problems than having to pull in a third party dependency now. Python changes in breaking ways--ju…

> and have major or glaring security issues

Telnet the protocol is secure if you either (a) use the Telnet ENCRYPTION option (such as with Kerberos ktelnet), or (b) run it over TLS (standard practice in IBM mainframe environments in which Telnet is still heavily used). Most Telnet clients and servers, this Python telnetlib included, never implemented either. But people present the protocol itself as being insecure, when it is just that the majority of implementations of it never bothered to implement the security extensions which have been defined for it. Telnet-over-TLS is just as secure as SSH. Telnet has the advantage of having various standardised extensions which don't exist in SSH, such as IBM 3270 and 5250 block mode terminal support, the SUPDUP protocol used by PDP-10s and Lisp Machines, serial port control (enabling you to configure baud rate/parity bits/etc if you Telnet to a serial port server), and Kermit. Now, you may not use any of those features – in which case SSH will suit you perfectly fine – but some people do. And, in principle someone could define equivalent extensions to SSH, but by and large nobody has done so, and even if somebody did, they wouldn't be standard so little or no software would support them.

Re: PEP 594 – Removing dead batteries from the standard library

#93

Post by waste_monk » Wed, Mar 16, 2022, 2:34 AM UTC

mark-r wrote: post #91

waste_monk wrote: post #89

Earlier quoted context omitted.

Because it prevents whole classes of support issues - if you can't install it, you can't raise a ticket complaining that something doesn't work under 7 and then waste support time... even if you say "if you're running windows 7 you're on your own" people will still try it on, or ask for one little tweak to make things work... all effort that could be better spent on forward progress or real support issues. It is far…

I consider "in the grave" to be a feature. It means Microsoft isn't trying to pull the rug out from under me each night with updates.

While that's true, you also aren't getting security updates - there have been 222 CVE score 7.0 or higher vulnerabilities for Windows 7 (all versions) assigned on or after the EOL date of 2020/01/14, some of which are rather nasty. While a couple of the most extreme ones did receive patches, the vast majority have not and a fully up to date Win7 system will be hugely vulnerable.

Given that any form of internet connectivity exposes you to a highly adversarial environment, I would personally be very uncomfortable persisting with Win7 - all it takes is one drive-by browser vulnerability and the attacker has a whole host of working exploits that can be used to further compromise your workstation.

I will not bother you further with the security aspect, but circling back to Python - your operating system does not exist in a vacuum, compatibility with Win 7 is actively degrading as it remains the same while Python and everything else continues to change, so it makes sense for them to prevent it being installed. That way the support community's time is not wasted even reading enough of a support issue to see that's on Win 7 and closing the issue - one or two in isolation would be tolerable, but in bulk even assigning or closing tickets would take a decent chunk of resources.

Re: PEP 594 – Removing dead batteries from the standard library

#94

Post by jppittma » Fri, Mar 18, 2022, 2:40 AM UTC

qbasic_forever wrote: post #49

c0l0 wrote: post #40

Earlier quoted context omitted.

HTTP Basic Auth over a secure transport (i.e., TLS) is not a "security issue".

It's a massive footgun and no sane security review would let a production service pass with HTTP basic auth. You're one misconfigured TLS proxy away from major security breaches and issues.

How many "ands" should a theoretical security threat have before you should just ignore the guy proposing it?

E.g.

If mercury is in retrograde and the stars are aligned and it's Tuesday and the hacker is in position with Wireshark running on windows XP with a tethered pine phone, and we accidentally open all our ports, then we're completely vulnerable --> Ignore that guy.

Re: PEP 594 – Removing dead batteries from the standard library

#95

Post by bariumbitmap » Fri, Mar 18, 2022, 10:27 PM UTC

nrclark wrote: post #16

There are some things on the list that I totally get. We probably don't need support for .aif files in Python's stdlib, or support for the Sun directory service. But I hate to see these get removed: - cgi - pipes - uu - telnetlib A lot of people still use CGI. Yes, it's slow / low-performance / etc. It's also a perfectly fine way to make a knockabout internal service. Pipes is a small pure-Python module, with nothing…

Indeed, the uu module is a short Python wrapper around binascii. It's only 206 lines, much of which is comments or docstrings:

https://github.com/python/cpython/blob/a5b7678a67ac99edd5082...

It has three functions: one to encode, one to decode, and one to show usage information and handle arguments. It's only had 3 commits since 2010. There just isn't much to maintain.