Just want to make clear that none of my comments are related to the reporter of the issue which started this tangential discussion. They seem reasonable from their previous messages, and don't want to give the impression that I think differently. I am just speaking generally based on trends that I have observed.
Guillem Jover <[email protected]> writes: > 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). I'm not really convinced it would help either. It seems fairly obvious that the mailing list is public. If you search anything along the lines of "inetutils bug report" or "inetutils mailing list" the archive will be the first result [1]. Aside from that, over the past few months it is nearly a daily occurrence that a public mailing list that I subscribe to has a "private security vulnerability" report. Every time it is an overly long, markdown-formatted, essay that tries to induce panic in the reader. Whether or not the issue is real is a coin flip. My worry here is that "help" means volunteering my inbox and time to verifying the output of noisy LLMs tested on Inetutils. That is not an opportunity that particularly excites me. >> > 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. Well, upstream maintainers and distribution maintainers are not the only people who control timelines. Security researchers have timelines too. It is mostly understandable; they and their employers have to eat too. However, some of it feels like unnecessary attention seeking. E.g., the recent obsession with buying a "*.fail" domain any time that you find a bug. Those personal annoyances aside, my main point is that if Simon or I do not fix the bug quick enough, we are effectively in the same situation. >> 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. I wish their point was that nuanced. But it was written in regards to this bug [2], right at the start of increase activity. Therefore, I feel like it is safe to conclude they were just being annoying. Collin [1] https://lists.gnu.org/mailman/listinfo/bug-inetutils [2] https://lists.gnu.org/archive/html/bug-inetutils/2026-02/msg00000.html
