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.
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.
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.
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
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.
https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...
That link goes to a page full of random garbage. No commits there to be seen.
Apparently the owners of that website don't like my choice of user agent, and have decided to punish me accordingly.
Same here. It says please wait while verifying.
1 reply →
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.
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.
7 replies →
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.
4 replies →
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.
7 replies →
Most 90’s era software had zero tests. Nobody gave it a second thought.
4 replies →
There's a famous XKCD about this: https://xkcd.com/2347/
In this case the hero's name is apparently Simon Josefsson (maintainer).
1 reply →
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
Telnet's cleartext and always has been. A backdoor seems like overkill.
You still have to know the password or snoop on someone typing the password. But with this vuln, you don't. You can just get root instantly.
> backdoor
Do you mean that it's intentional? Why do you think so?
It wasn't a backdoor, just a very serious security bug. Congrats on jumping straight to conspiracy and paranoia, though.
It's only a conspiracy and paranoia if it's wrong. 11 years ago was 2015.
It is wrong. The author is known, was acting in good faith, and simply fucked up really badly.
I don't know what 11 years ago has to do with anything, besides the awful lifespan of such a severe bug.
> GNU organization
> giant security flaw
Checks out.