Re: security alerts in busybox

On 4/26/26 18:09, Roberto A. Foglietta wrote:
> On Sun, 26 Apr 2026 at 18:01, Tim Tassonis via busybox
> <[email protected]> wrote:
>>
>>
>>
>> On 4/26/26 10:42, Roberto A. Foglietta via busybox wrote:
>>> On Sat, 25 Apr 2026 at 21:46, Ladislav Michl <[email protected]> wrote:
>>>>
>>>> On Fri, Apr 24, 2026 at 04:40:47PM +0200, Roberto A. Foglietta via busybox wrote:
>>>>> Hi,
>>> ...
>>>>> These are trivial alerts, therefore I faced it first to provide an
>>>>> example. And the second main question is straightforward: does this
>>>>> fix worth 177 bytes? In relative terms it is 150 ppm compared with the
>>>>> full size footprint. In terms of certifications is a solid step
>>>>> towards peace of mind.
>>>>
>>>> These are not trivial alerts, but pure garbage. Adding even single
>>>> byte to 'fix' non-existant bug does not make any sense.
>>>>
>>>
>>> It doesn't make any sense for you, but for busybox as a single binary
>>> self-contained is a must to have.
>>>
>>> The core technical point: Busybox is not pthread-safe by design, but a
>>> self-contained binary must be. Therefore static-analysis alerts that
>>> are 99.9% false-positive in multi-process Busybox become mandatory
>>> fixes in single-binary deployment. This is a genuine architectural
>>> distinction that bureaucratic tool-wrangling would miss.
>>
>> Who the fuck apart from you has ever claimed that a self-contained
>> binary must be pthread-safe even it does not use threads?
>>
>> I really begin to wonder if you're actually for real, or just some
>> rage-bot written to churn out useless trivial bullshit security
>> enhancements and then defend that crap against all valid objections with
>> unfounded, far-fetched or downright wrong arguments.
>>
>> A self-contained program not using threads and not using library
>> functions that use threads. does not have to be thread-save, that's why
>> it's called thread-safe.
> 
> As previously told you, fight against a machine before engaging humans.
> 
> The first prompt, as an example, I pushed for you into the machine:
> 
> ‘As a self-contained binary that never forks or threads, the process
> operates within a single deterministic address space where memory
> isolation coincides with the process’s own lifecycle, rendering thread
> safety unnecessary but making local resilience against side-effects
> critical.’
  > Please, do not bother me anymore. I am not your secretary, prompt the
> machine directly. The man in flesh and blood is available only for
> deep-pockets customers.

That's fine with me, then just ignore me, while I do read your responses 
and sometimes find parts of it interesting or at least funny, I'd rather 
spend my money on a can of heat.

Anyway, your machine-generated, highly buzzword-obfuscated (I assume 
that's a desired feature of that machine, making trivial crap sound 
somewhat more academiccy) paragraph that for the most part boils down to 
nothing at all, it even got me to lookup the one actually claimed 
advantage: side-effects.

Don't bother to reply to this for free if you don't want to, but after 
careful reading of 
https://en.wikipedia.org/wiki/Side_effect_(computer_science), I come to 
the conclusion that with regards to thread-safety in a non-threaded 
program, this also boils down to: exactly, absolutely and categorically 
nothing.


Bye
Tim



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