Re: security alerts in busybox
"Roberto A. Foglietta via busybox" <[email protected]> Mon, 27 Apr 2026 20:39:56 +0200
| Newsgroups | gmane.linux.busybox |
|---|---|
| Message-ID | <CAJGKYO6vgFS3mA=fgJz-5ySuVNmeCSncmM0veiRsCJG8wHyrzQ@mail.gmail.com> |
On Mon, 27 Apr 2026 at 19:28, Hans Ulli Kroll <[email protected]> wrote: > ... > > The changes are simple and understandable. good, I like you like > > But your commit message says only fixed issue number *something* So what? > > i.e. for ctime > > If you have done this > > snip -> > > FIX: call of ctime() user safer ctime_r() > or > FIX: use of safer ctime_r() > > .. here maybe some smaller or bigger explanation. > > snip -> > > This above is a *good* commit message, which will also be accepted on > lkml. This is not lkml, that branch isn't about the kernel. > > -- now here all files you have touched, in one go -- > > This makes for these fixes, three commits. Four commits each for ctime, gmtime, localtime + libb. Or 45 commits by each report number + libbb. Ore 23 commits on file basis + libb. Or one for a single "recursive time function replacing for threats safety" > > > > > > Few consultancy companies and a couple of linux distributions will > > > face a nightmare in justifying their past conduct with their clients? > > > Not a problem of mine, again. > > > > > > Please, push forward this theatre. So, managers and CEO can justify > > > themselves with "it is a complex matter, there is no consensus among > > > technicians also". We just heard this stuff about other crysis, right? > > The whole thing is already solved in the EU. Maybe. Conclusion It is not just about security, I wrote in first place that from a security PoV I consider these 44 alerts about ctime, gmtime, localtime, can be easily considered false positives. I have also explained that it is a move towards supporting alternative approaches to fork(), like NOMMU vfork() even threads in such infrastructure in which efficiency is a matter of scaling. Keep in consideration that this long and convoluted e-mail create distress in technical m-list. If you have to ask something -- do it plain clear When you review a patch that is sent here -- do line by line Follow these two basic rules, then later we might drink a beer at the pub and talk about fancy stuff. Best regards, R-