That's crazy. This is core business critical software but they just YOLO critical changes without any automated tests? this PR would be insta-rejected in the small SAAS shop I work at.
back
8 comments
If you think you can do better you're welcome to do better. I say this without a hint of sarcasm. This is how open source works. It's a do–ocracy, not a democracy. Whoever makes a telnet server gets to decide how the telnet server works and how much testing it gets before release.
Maybe the lesson here is to stop letting the GNU folks do things, if this is what they do. This is only one example of craziness coming out of the GNU camp.
Or, flip the responsibility to what it has always been understood to be, when using open source software from random volunteers (some being bad actors) on the internet for anything remotely critical: audit the source.
GNU doesn’t provide labor, only organizational tools like mailing lists and whatnot. The projects that GNU supports are still run by individual volunteers. If you want it done better then please volunteer so that you can be the one doing it better.
I am the one doing it better. GNU software is slowly being deprecated on my system, starting with glibc.
So you’re just changing which volunteers you depend on? That’s really productive of you. Thank you for your service.
You can enslave yourself to Microslop if you prefer.
Culture has changed a lot since the 20th century and older projects can have antiquated norms around things like testing. I was just listening to a recent podcast talking about how worrisome it is that OpenSSL has a casual culture about testing[1] and was reminded about how normal that used to be. I think in the case of telnetd you also have the problem that it’s been deprecated for multiple decades so I’d bet that they struggle even more than average to find maintainer time.
1. https://securitycryptographywhatever.com/2026/02/01/python-c...
Even with automated tests you'd need to think of this exploit right? Perhaps fuzzing would have got it. The mailing lists says they proved it successful on
- OpenIndiana
- FreeBSD
- Debian GNU/Linux
So not complete YOLO.
See https://lists.gnu.org/archive/html/bug-inetutils/2015-03/msg...
FWIW, a well known LLM agent, when I asked for a review of the patch, did suggest it was dodgy but didn't pick up the severity of how dodgy it was.
> a well known LLM agent
Which one?
Not GP, but my local Ministral 3 14B and GPT-OSS 20B didn't catch anything unless I gave some hints.
He says 'well known' so I assume Claude or GPT, I just don't get why he's being coy.
I thought by not naming it wouldn't shift the focus to the particular model, but it did the opposite. It was gpt-5.3-codex in medium mode.
Any business that has a telnet daemon able to be reached by an unauthenticated user is negligent. Just the fact that everything is in the clear is reason enough to never use it outside of protected networks.
unless it doesn’t matter if it’s evesdropped
Traffic could be tampered as well.
Sometimes that doesn't matter either. That is the valid use case of a plain-text protocol like telnet: doesn't matter.
Sure. But, contrary to what some people seem to think, "it's nothing secret" is not a sufficient justification to use an unencrypted plain-text protocol.
It literally is. I do not give a fuck if someone reads or fakes the wind speed from the sensor on my roof.
Yeah but you probably don't have that telnet server exposed to the internet. It's fine if it's all local, I have an unencrypted FTP server running on my Xbox but it would be insane to let that be accessible from the internet.
My point is that it's ok to use unencrypted plain text if you don't care if it's read ("it's nothing secret"), AND furthermore you don't care if it's modified.
If you don't care that it's read ("it's nothing secret"), but you do care that it's not modified, you should not use unencrypted plain text. That's why I explained that if you don't care if it's read that is not a sufficient justification to use unencrypted plain text, because then it might be modified, and you might care about that.
You then said that it "literally" is: if you don't care if it's read ("it's nothing secret") that is a sufficient justification to use unencrypted plain text.
But then you proceed to give an example where it is, indeed, ok to use unencrypted plain text, but only because you don't care if it's read ("it's nothing secret"), AND you don't care if it's modified. That is what I have been saying all along. If you were to care that the wind speed from the sensor on your roof is not faked, then you should not use unencrypted plain text.
So again: If you don't care that it's read, AND you don't care if it's modified, then, sure, use unencrypted plain text.
If you don't care that it's read ("it's nothing secret"), but you do care that it's not modified, that is not sufficient justification to use unencrypted plain text. Rather, in addition, you also have to not care if it's modified.
Let me give you an example. Air pressure varies, and airplanes use air pressure to measure altitude, so they need to set their altimeter to the correct air pressure. Now, the air pressure is not secret at all. Anyone could trivially measure it. So, one doesn't care if it's read ("it's nothing secret").
According to your faulty thinking, one could thus use unencrypted plain text to transmit it. However, someone could modify it, giving wrong numbers to the airplane, putting the airplane and the crew in danger. That is not good. No-one cares that the data is read ("it's nothing secret"), but we do care that it is not modified. Thus, do not use unencrypted plain text. Because if you don't care if it is read ("it's nothing secret"), that is not sufficient justification to use unencrypted plain text. You have to, in addition, not care if it is modified.
In your case, you don't care if it is read ("it's nothing secret"), AND you don't care if it modified. But someone else might not care if it is read, but DO care if it is modified.
Do you understand this now, or should I make a full 2x2 matrix with all possibilities and carefully explain each case with examples?
Most 90’s era software had zero tests. Nobody gave it a second thought.
This is quite untrue as a blanket statement. The problem is that there was massive cultural variation: if you installed a Perl module from CPAN you probably ran hundreds of tests. If you ran a C program, it ranged from nothing to “run this one input and don’t crash” to exhaustive suites. PHP tended towards nothing with a handful of surprises.
As a data point, my first tech job was QA for a COBOL compiler vendor. They supported roughly 600 permutations of architecture, operating system, and OS version with a byte-coded runtime and compiler written in C. I maintained a test runner and suite with many thousands of tests, ranging from unit tests to things like Expect UI tests. This was considered routine in the compiler vendor field, and in the scientific computing space I moved into. I worked with someone who independently reproduced the famous Pentium FDIV bug figuring out why their tests failed, which surprised no one because that was just expected engineering.
Then you had the other end of the industry where there was, say, 50k lines of Visual Basic desktop app where they didn’t even use version control software. At a later job, I briefly encountered a legacy system which had 30 years of that where they had the same routine copied in half a dozen places, modified slightly because when the author had fixed a bug they weren’t sure if it would break something else so they just created a copy and updated just the module they were working on.
True, it is colored by my own personal experienced. I remember CPAN, perl, and installing modules with tests. I also remember my day job: a 500,000 line C and C++ code base with literally 5 automated tests that nobody ever ran!
Yeah, I think it’s really hard to understand how much more cultural variation there was without first the internet and open source, and then services like GitHub, GitLab, BitBucket, etc. converging people onto similar practices and expectations.
Early '90s maybe. By the late '90s people knew tests were a good idea, and many even applied that in practice.
There's a famous XKCD about this: https://xkcd.com/2347/
In this case the hero's name is apparently Simon Josefsson (maintainer).
I feel like we should just start saying 2347. Everyone knows what you mean.
https://xkcd.com/2347/
Ah, someone beat me to it!
It can't be critical business software if the business to which it is critical isn't paying anything for it.
/s