Does fixing security faults in telnetd simply encourage people to use it? IOW, would deliberately _not_ fixing them be a better strategy? I suppose that argument could extend to: would it be good to _introduce_ security bugs to telnet, overtly?
@jmtd Unless you think that being a cleartext protocol itself counts as a "security fault", such bugs absolutely should be fixed if reasonable to do so. A user might be just fine with cleartext (perhaps they're using it over a LAN or VPN, or are running a non-login service such as a MUD), and wouldn't particularly appreciate you having basically backdoored their binary.
@pndc I wouldn’t describe a vulnerability as a back door unless it was not well known or deliberately obscured. I do feel the plain text nature of telnetd is a fault, yes, but I appreciate others may not. There are other decision decisions I also feel are faults (e.g. accepting the client’s ENV). Also, it’s de-facto unmaintained.
@jmtd "would it be good to introduce security bugs to telnet, overtly?" is still a back door if the "overtly" is in some documentation or source code that the user is unlikely to read.
@pndc yes. To be clear that was an extrapolation of my argument to not fix known issues; I don’t feel it should be done!
- replies
- 0
- announces
- 0
- likes
- 0