Re: security alerts in busybox

On Sat, 25 Apr 2026 at 17:26, Tim Tassonis via busybox
<[email protected]> wrote:
>
>
>
> On 4/24/26 16:40, Roberto A. Foglietta via busybox wrote:
> > Hi,
> >
> > Using a static code analyser, I found:
> >
> > Open potentially alerts by severity/class in branch `main`:
> >
> > - **security**: 103 critical, 96 high, 4 medium, **203 total**
> >
> > Alerts above are related to C-language code, none otherwise.
> >
> > Are these false positives? Well, it is more about corner cases like
> > using the applet in a strong parallel mode like xargs -p8 does. If
> > used for maintenance on a large enough infrastructure, the corner case
> > has a chance to be met, for example.
> >
> > https://github.com/robang74/busybox/commits/security/
>
> I looked at a few of those fixes, they seem to contain a lot of cases where
>
> ctime gets replaced with the thread-safe" ctime_r
>
> (for instance in ar.c)
>
> looking at the function, the value is only used in a printf a little
> later, so your "fix" accomplishes exactly nothing at all except to make
> the static buffer visual in the code.

In a single process like usually busybox is, it would not be a problem either.

Something that I did not have a problem to admit, but (listed corner cases).

And that corner cases are altering the static internal ctime() buffer
and reading it isn't an atomic operation. Something  that busybox
developers were aware about because of the comments that they left in
the code and how they use multiple printf instead of single with
multiple ctime calls.



>
> Now, for a program such as busybox that aims to be as compact as
> possible, I would rather call this a new defect than a security fix.
>
> Just complaining about non-reentrant functions with static buffers is
> quite a lame way of "adding security", when no threads are used and the
> static buffer is only used once.
>
> It's a bit like encrypting with 512 bit aes, or using password with a
> length of 64 characters...
>

bla-bla bla-bla bla-bla, there is no consensus among technicians show.

Certification isn't about it being useful but it fits into some
standards. Safety isn't about doing "strange things because it is
**almost** safe" but to challenge the code against those tools that
are supposed to certify safety.

Finally size isn't a problem either because changing properly the
compilation/linking options the size is about 1/3 being reduced (as I
am used to do in uchaosys, not a secret):

+:git-shell:security:busybox> size busybox
   text    data     bss     dec     hex filename
2771948   40005   29722 2841675 2b5c4b busybox
+:git-shell:security:busybox> file busybox
busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked,
BuildID[sha1]=eb2a5a8906d1714add1382d90662a960d4e432a6, for GNU/Linux
3.2.0, stripped

Curiously, people who are involved in this debate wish to impose their
standard to others but they would accept that there are already
standards out there. In many industries those standards aren't
optional but mandatory. While your judgment is totally arbitrary, my
dear Me Tassonis especially because you are not forced to use busybox
from my repository.

So, if busybox maintainers were questioning themselves because they
are treated like "weird" people, now I desveil the mystery: they are
subjugated by political debates of people that aren't able to
understand the fundamentals of responsibility and accountability.
After all, if you do not care about the "business", then do not merge
the branch security in the master and live without it (and in the same
specific cases, it makes sense go for that way and I cited a case that
is fine for millions of end users).

Conclusion: your opinion has no value, altogether. Even if the busybox
is compiled static and used in a single process constraint mode. Mine
is very well founded into a single principle: some out there need that
code be cleaned by "corner case, even almost impossible". Written by
one person that solved a "corner case near impossible" that was
forcing rebooting and destroying the filesystem into a freshly
installed industrial line production by a great company and supported
by a great consultancy company.

--> Who initially wrote the code did not take in consideration that
who would have integrated and deployed would have used pthread instead
of forking.

Therefore, I am not writing on the behalf of a theoretical PoV but
real-word experience in which a lot of money was involved in penalties
and damages. Do not you like this experience of mine, free to continue
to develop your "precious" busybox into your own garage. I would not
stop you, for sure and not even debate about it. Soon you realise that
you are still free to continue to go by your own way, sooner we will
be all happier.

Best regards, R-