security alerts in busybox

[Tim Tassonis]

On 4/25/26 17:07, Roberto A. Foglietta via busybox wrote:
> On Sat, 25 Apr 2026 at 16:19, Hans Ulli Kroll <linux at ulli-kroll.de> 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
> 
> A change that weighs 193ppm (part per million) on overall full-feature
> stripped busybox dynamically link thus less impactful (98ppm) on a
> static compiled one which for almost all the case cannot be affected
> by those problems, e.g, the Intel/AMD or ARM64 into Ubuntu.
> 
> +:git-shell:security:busybox> size busybox
>     text    data     bss     dec     hex filename
> 3518497   40022   29674 3588193 36c061 busybox
> +:git-shell:security:busybox> file busybox
> busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
> statically linked,
> BuildID[sha1]=145e8f3edc796b67e5efc42d8e162d770e51c695, for GNU/Linux
> 3.2.0, stripped
> 
> 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.
> 
> 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?

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

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.


Regards
Tim