Re: security alerts in busybox
"Roberto A. Foglietta via busybox" <[email protected]> Sun, 26 Apr 2026 18:09:54 +0200
| Newsgroups | gmane.linux.busybox |
|---|---|
| Message-ID | <CAJGKYO7oM=Y9OUo50ZGYnPhsmUBhYubmabCfdO1M=wpT2zTnPw@mail.gmail.com> |
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. Best regards, R- _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox