Re: security alerts in busybox

On Sun, 2026-04-26 at 18:29 +0200, Tim Tassonis via busybox wrote:
> 
> On 4/25/26 17:07, Roberto A. Foglietta via busybox wrote:
> > On Sat, 25 Apr 2026 at 16:19, Hans Ulli Kroll <[email protected]> wrote:
> > > 
> > > On Fri, 2026-04-24 at 16:40 +0200, Roberto A. Foglietta via busybox
> > > wrote:
> > ...
> > > > 
> > > > https://github.com/robang74/busybox/commits/security/
> > > > 
> > > > commit f69e57f62798ae2bca9f5071adb45bfb002002b1 (HEAD -> security,
> > ...
> > > besides the ongoing discussion ...
> > > which may or may not helpful
> > > 
> > > your commit message makes no sense.
> > > 
> > > YES I can read the code too,
> > 
> > I hardly can believe that, if you would be able to, then you have
> > noticed that the trivial fixes belong to all the same class:
> > 
> > ctime -> ctime_r
> > gmtime -> gmtime_r
> > localtime -> localtime_r
> > 
..

> > So the changes are self-explicative and why did I did them? Because
> > that changes are trivial, adds almost nothing and strongly makes every
> > certification process much easier. Obviously, other issues aren't
> > necessarily so trivial in being solved in a proper/acceptable manner
> > for busybox. And again, no explanation should be given because a) the
> > code is self-explanatory and b) GPLv2 implies only sharing the code,
> > not explaining anything further.

THIS is what I said.

The changes are simple and understandable.

But your commit message says only fixed issue number *something*

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.

-- now here all files you have touched, in one go --

This makes for these fixes, three commits.

> > 
> > 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.

Called CRA or NIS2 if you like
This is very complex. 
This drills down no only to security but also trust.

I my area I happily throw big money out of the window, to get "this
service"

Also I now, because I saw, the logs some open source software is used
in their critical environment or subcontractors.

> Well, there actually is quite an established consensus among experienced 
> technicians that just switching to only theoretically safer functions 
> for the sake of passing uninformed tests rather decreases practical 
> security, as it wastes resources that would be better spent on actually 
> existing problems.
> 
> And like in real life, the argument of "well, it might not really help, 
> but it can do no harm" can be very problematic, as it often leads to a 
> false sense of safety. We all know the saying "They got ten locks at the 
> front door, but the backdoor is always open".

ACK.

> 
> And I think randomly replacing ctime with ctime_r is exactly that: just 
> another needless lock at the front door.
> 
> I bet that 90% of all somewhat critical security issues published in the 
> last two years would have passed the security checks of your tool.

This is worse.

I you have a checker for only i.e. libc function, someone writes a
wrapper to comply the tests.

And if have only the binary, who knows ?

Static tests on binaries are (mostly) not helpful at all.
compilers doing optimisations and kernel developers trying to be
smarter and trick around optimisations because of hardware


> 
> Regards
> Tim
> 

Ulli
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox