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-