Portability. A test to get the answer to "what the fuck am I running on and what does it support" is more portable and robust than thousands of "flavours" manually configured in /etc/whatamieven.conf
The author misses that the buildtime magic for the xz exploit is not in the m4 file but in an obfuscated, compressed, encrypted, binary disguised as a test file that alters the build process at multiple stages (configure and build)
A better argument can be made that the act of compiling a binary / obfuscating / minifying code instead of interpreting code directly is the fault.
That means it's totally normal to ship all kinds of really crazy looking stuff, and so when someone noticed that and decided to use that as their mechanism for extracting some badness from a so-called "test file" that was actually laden with their binary code, is it so surprising that it happened? To me, it seems inevitable.
Yeah, no. The author is well aware of how and why autotools are not awesome but also with the background of why they exist.
A better argument can be made that the act of compiling a binary / obfuscating / minifying code instead of interpreting code directly is the fault.
I can’t decide if you’ve never worked in systems software or trying to be hyperbolic. Given that it’s HN I’ll assume the best. But who do you think would do the interpreting? The priests at Delphi?
configure is a mistake. Building a project shouldn’t generate input files that are dependent on the system state. That’s what C projects from the 90s do and it’s genuinely awful.
What is the alternative? Even if you're very organized and abstract away all the stuff into neat platform-specific modules, you'll still have those system-dependent inputs in the build system. No matter what happens it will still have to pick which of those modules to include in the build and it will most likely do so via some target variable whose default value is whatever it autodetects the host system as.
You mean a 64bit architecture literally cannot handle an 8bit instruction as its smallest register is 16bit without swapping modes?
Where did you get that piece of misinformation from? 64-bit x86 can handle 64, 32, 16, and 8-bit data just fine, and its instructions are still byte-aligned.
Also, the decision to remove 16-bit support from 64-bit Windows was entirely political. NTVDMx64 adds it back.
It gets abandoned but unlike closed software, if you depend on it enough, you can continue using it forever. For some reason if GitHub says ‘updated 6 years ago’ it is not viable for people, but for many things, especially desktop apps, this doesn’t matter at all; it works fine and if you need updates, you can do them.
The point is you can, while with closed software, you maybe can and sometimes with a lot of trouble.
If the source is open, the file format is also open.
I agree, provided the software isn't network reliant / accessible.
If the software were to explicitly depend on <vulnerable library> and moving to <patched library> broke it that would be the nail in the coffin for me / make me question whether I want to spend the effort maintaining the project.
Yes, but for desktop software this is usually less of an issue. And at least you could fix it. When people are running ancient closed source software on Windows (Win 95 software apparently runs on Win 11), they don’t even think about the vulnerabilities and if they do, they cannot fix them. If you are so married to a software like the author seems to be, open is your best bet. And the OP is retired (well, at least 2021), so tinker time!
This genuinely just reads like a bucket list of Mac user problems.
The author would genuinely benefit from redhats decade long support models provided his desired tooling works on Linux.
The real concerns are in the SaaS / Remote Resource / Online Activation Space.
eg software that won't wake up if it can't call home, software that has reduced or no functionality if it can't stream remote data, "apps" that are just webkits loading a pre-set url for a completely online service.
