Re: Security Vulnerabilities in inetutils telnetd
Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Fri, 29 May 2026 10:39:23 +0200
| Newsgroups | gmane.comp.gnu.inetutils.bugs |
|---|---|
| Message-ID | <[email protected]> |
--=-=-= Content-Type: text/plain Note: This is in no way meant to diminish Tal's work, and the following is meant as a general discussion about security reporting. Guillem Jover <[email protected]> writes: > It does not help that there's no mention of the bug-inetutils address > being a publicly archived mailing list in the codebase. I've mentioned > that it would be nice to clarify this in the README, and ideally provide > a private method for security reports (either an email address or suggest > filing confidential ones on codeberg f.ex.), but this was dismissed and > it was stated that sending these kind of reports to the list was good > because more people then can help. What do you think about this suggested policy change? https://codeberg.org/inetutils/inetutils/pulls/26 I did not dismiss the suggestion to have a private reporting method, but the amount of crap reports I receive to my private inbox makes me hesitant about offering that as a default supported route. But we can try it to see if it leads to any improvement. When I ask people to make their report public, they sometimes refuse presumably because they realize it was a five minute AI slop work that will consume hours to understand and isn't uncommon to be invalid. I wish there were better ways to handle this asymmetric situation. FWIW, we've received Tal's report in private and are working on patches and allocating CVE identifiers. This will take more time than if that effort was done in public (e.g., both Collin and I are away over the weekend) where you and others could help to do the analysis and review patches. I'm not convinced that slow-down and closed nature of development, with reduced quality of review, is in the best interest of our users generally. Several of the InetUtils network servers implement inherently insecure protocols. Often the environment required to run these services securely in the first place (e.g., external VPN connection to a telnetd server) mitigate many security concerns. Suggestions how to better explain this aspect to users in the manual would be appreciated, but I believe it ought to be well understood through any modern literature about TELNET. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmoZULwUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4fWRBQkOa+rdAAoJENc89jjFPAa+hWIA /1lQvrJeGlQq50lP6tm99D1zDy7J1tQ3ha4x0Jx7rkFTAP9hpUKuTvm6m1fXyiZV YZlu2+Id/Dq3CIAZvNF+XEr2BLgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCaeCW1wUJDmqLVgCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+s7AA+gIIHpBApDpcDj1sKhzDngmpvwQf0VkHme6s+EG7qSgpAQDe /XMrU0c0Pa3ji85cMqZhvzJOFI/soe662lzL0QY3Bbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4JbXBQkOaottAAoJENc89jjF PAa+RNUA/2faQO/nFT06E+MlhlQdo/0chlQXC5TZMPTVvVBFwoLOAP9xLJK0ow5E jTzYJB4K810AL/Iv6PEOAEgA4cPTHVlbCQAKCRBRcisI/kdFoqbjAQDowmOpVPb2 tbrlXIPzMiXQCqulrzn/bDPoKUX92tncewEA5vKFYbdSKg/1aLT3Kf60u0iVt5+L PK89n3pxfz7GwAA= =OOYY -----END PGP SIGNATURE----- --=-=-=--