Hi! On Thu, 2026-05-28 at 08:45:08 -0700, Collin Funk wrote: > Guillem Jover writes: > > Thank you for your thoughtfulness about the disclosure process! Really > > appreciated. While I'm not an upstream GNU inetutils maintainer (I just > > maintain the GNU inetutils packages in Debian), the current disclosure > > stance from upstream has caused extra pressure and undue burden into both > > the distro maintainers and their security teams, to try to get together > > fixes to be able to release security updates for those distros, > > Well the last serious, for lack of a better term, issue was from an LLM > thinking that it was reporting a bug privately.
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. Of course this would require for a maintainer or a set of them to have to take care of handling these reports, which they might not be willing or able to handle (due to time commitments or whatever). For context, in Debian during the inetutils 1.7 cycle I count 3 security uploads for stable, 3 for oldstable, and 2 for oldoldstable, and 4 uploads fixing security issues for unstable. This involved handling by multiple maintainers and the various security teams, and backporting patches depending on newer gnulib modules not present in older Debian releases that shipped with earlier inetutils versions. (https://tracker.debian.org/pkg/inetutils) > > while there were either no releases from upstream or no ready fixes, > > which for the last iteration lasted for weeks. :/ > > I think that is important to note that I see absolutely zero benefit > from working on Inetutils. Monetarily, of course not. I would certainly > prefer spending my free time doing literally anything else. I cannot > speak for Simon, but I would not be surprised to hear the situation is > the same for him. Maybe my comment might not have come across in the way I intended it (?). I think (upstream) maintainers should be able to work on a project at their own pace, but asking for security reports to be sent to a public mailing list, including enough detail to weaponize such issues, is going to create this kind of pressure/environment. > In fact, working on Inetutils probably harms my reputation. That is > probably exaggerating, but it is annoying to read the serial whiners at > watchTowr Labs say stupid stuff like this: > > Shamefully, the inetutils project hasn’t actually released a fixed > version of their software (at least at the time of publishing). The > newest version available for download - 2.7 - is still vulnerable. > You’ll need to make sure you clone a fixed commit from git (this one > or newer) and build from source. > > As if creating a new release is easier for distributions than a patch. While I don't agree with this kind of commentary, at the same time I can also understand where it is coming from, and it seems it's caused by the combination of maintainers for which the project might be either a burden, or where they might have their plates full with other projects (which they might consider more important, or more enjoyable or whatever), and having no recommended private security reporting in place, where these kinds of issues can be coordinated at leisure whenever it's more convenient for them. > That said, I think waiting two weeks is better than never receiving a > fix at all. For a project that is primarily a set of network tools, I don't feel I can (in general) wait that long in Debian for fixes to appear if the reports have been made public. So, I need to take action before that, which also implies involving other teams. Also for example, Simon has asked in the past to enable some more tools in Debian (rsh-client, rsh-server, tftp client), where I already had my reservations, but given the current upstream security reporting posture, I feel my reservations have substantially grown due to that. Thanks, Guillem
