security alerts in busybox
Tim Tassonis
stuff at decentral.ch
Sun Apr 26 20:57:34 UTC 2026
On 4/26/26 18:09, Roberto A. Foglietta wrote:
> On Sun, 26 Apr 2026 at 18:01, Tim Tassonis via busybox
> <busybox at busybox.net> wrote:
>>
>>
>>
>> On 4/26/26 10:42, Roberto A. Foglietta via busybox wrote:
>>> On Sat, 25 Apr 2026 at 21:46, Ladislav Michl <oss-lists at triops.cz> 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
More information about the busybox
mailing list