Hacker News Reader

Comment by qbasic_forever | Hacker News Reader

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--just look at the python 2 to 3 change. You will have to learn to deal with it. There is no explicit guarantee that python will continue to work in exactly the way it has always worked for you forever.

View on HN

what's the major glaring security issue of cgi that you would consider a dealbreaker for a simple http-based service?

(this is an honest question, because when I saw this list I actually have a python script running on an apache web server that is using the cgi module to access post variables, and I never saw any need to change that, as any other "more modern" solution would be much more bothersome to configure and maintain.)

What is your auth and session story? Because I doubt you're implementing OIDC, JWT, etc. in a cgi script vs. relying on a modern framework that does all the work for you. HTTP basic auth? Well, there's your security issue right there.

So presumably you are happy to have a web accessible endpoint running on your server that will pop a new process and start executing a local script (which might be reading/writing files, other services, etc.) without checking any permissions, enforcing any cross site scripting or CSRF protections, etc. It might be fine for the most trivial appplication. For anything that actually changes state or has side effects, I would be very concerned and it would never pass a serious security review.

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.

Uhhh what? Do you think either

* basic auth only exists at the proxy layer to protect apps with no auth.

* commonly deployed auth systems are secure without TLS?

because both are false. Check out the Rails Devise support for HTTP basic auth which is perfectly secure. And check that basically zero auth systems in the wild use PAKE and so are entirely dependent on TLS to secure the password transmission in flight.

I hate this argument. I hear it all the time. It's wrong and silly.

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.

Firstly, HTTP Basic auth is not a problem over HTTPS (and it will be HTTPS more often than not, given modern browsers are bound to criminalise HTTP soon). Even then, putting an authenticating reverse proxy in front of such a site is dead-simple, and that can use wherever auth is required.

Secondly, chances are that if you're building a CGI site, you won't be exposing it to the outside world at all because it's internal/personal jank that's built to do a single job, and not to look nice. If it's meant to look nice and and handle the stress of being used by a public userbase, then it won't be CGI in the first place.

I don't really see the connection between cgi and http basic auth. These seem orthogonal issues.

(And fwiw the usecase I have does not have any authentication and doesn't need any. It's taking a POST var and doing things with it, but there are no secrets involved.)

WebOb uses cgi for parsing multipart uploads/forms...

It's not obsolete, and it is heavily used, it's working software that works well. Ripping it out just means now there will be N copies floating around that will all need to get patched/fixed instead of just a single version included with Python.

Well apparently it's not heavily enough used that any of its current users were motivated enough to discuss the PEP and make a strong case for keeping it in the standard library. The discussion was open for _three years_ and had hundreds of comments: https://discuss.python.org/t/pep-594-removing-dead-batteries... The outcome is that there isn't enough usage to merit this being in the standard library.

I suspect there's very little overlap between users of development software and participants in the bureaucracy that designs the software. The requisite personality types are very different.

If you're developing software that depends on a python standard library it is on you to subscribe to the relevant mailing lists so you can be notified of security issues, deprecations, changes, etc. There is not bureaucracy here to be aware of what's happening, or even comment on the changes.

Years ago I used to do that. But nowadays I use so much external stuff it's impossible. So I'm actually immensely grateful to the Python team for including so much in the Standard Library and maintaining it for decades - because for me, at least until now, it's been that one part where I could relax a bit about and be confident that competent people will take care of everything and I won't need to spend much time analyzing the situation.

Seems to me that this is exactly the problem. The python team is saying they really can't maintain these libraries to a high standard and need to remove them from the standard library. I can see both sides but really that makes a lot of sense to me.

https://discuss.python.org/t/pep-594-removing-dead-batteries...

Is my comment. It's the 6th comment down. Clearly I didn't make a strong enough case, but I certainly did advocate for it and mention that it is in use.

Since NNTP was my gateway to open source, I'm somewhat sad to see Python's nntplib module die... but NNTP is quite well advanced in its way out. If you were asking a decade ago, NNTP would be a relatively niche community that potentially had some relevance, but posting volumes not associated with alt.binaries has declined precipitously in the past decade alone (judging from aioe.org's statistics, it's a third of in 2022 of what it was in 2012, and even that feels generous).

I can understand some concern about the impact of removal of support for deprecated things where it potentially impacts archival scenarios (e.g., uuencoded text), but dropping NNTP from the standard library is probably the right call for Python. It's not like the protocol is so complicated you need a library to do it for you, anyways. ;-) (To be fair, I often use NNTP as my example protocol for implementing stuff because of its simplicity.)

> 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.

Reply on news.ycombinator.com