“This removes a.out support globally”
git.kernel.org
git.kernel.org
Below is the description written by Dennis Ritchie in the 1971 documentation:
> "a.out is the output file of the assembler as and the link editor ld. In both cases, a.out is executable provided there were no errors and no unresolved external references. This file has four sections: a header, the program text, a symbol table, and relocation bits. The last two may be empty if the program was loaded with the —s option of ld or if the symbols and relocation have been removed by strip."
Last release of Mastodon Linux is 2002, a lot later than I would've thought.
Excerpt:
--
Kees Cook did do a little research on, seemingly, the only distribution that still supports Alpha (Gentoo) and found that the only ECOFF files present contained firmware, which does not run on the CPU anyway. He concluded that there would be no harm from removing a.out support on this platform: ""Let's do it"".
It seems to be a universal rule that somebody always has to come along to ruin the party. In this case, just as it seemed like there were no further obstacles to the removal of a.out, James Jones showed up to let it be known that he was still using a.out:
The use case is running an old set of tools to build programs for the Atari Jaguar. Namely, Atari's assembler (mac) and linker (aln). The alternative is running windows versions in dosbox, or using some replacements that have been developed based on an even older, less-featureful version of the source code for mac and aln, but which still haven't managed to add back in all the features needed to build some programs or use the Atari debugging tools (Also available in a.out only)."
--
And here the HN discussion on said article: https://news.ycombinator.com/item?id=30792059
I mean, dropping a.out support is not a retroactive change.
/\* This should be unreachable. \*/
fprintf(stderr, "They found me. I don't how, but they found me.\n");
He's working on decades old platforms...this really shouldn't phase him.
Don't break the user and sanctimoniously pretend you're doing everyone else a favor.
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
That compression format should have been aggressively removed once the flaws were uncovered. It presented a real-life danger on so many fronts. Imagine engineering documents, medication orders, architectural specs, you name it. That compression algorithm easily could have killed people.
JBIG2 came out around 2000, when the compression issue went public in 2013 it was in widespread use by many Xerox scanners that could scan to PDF and could not be turned off. Of course as non American I have only heard that xerox is synonymous with copying so I might misinterpret the impact the issue had.
> b)in the few examples they did, it was quickly found to be harmful, modifying digits and letters.
If I understand it correctly the refinement encoding that was exploited in this case would have prevented the replacement issues by storing visible differences along with the glyph replacement. However Xerox did not seem to make use of this feature, resulting in the problematic changes even at the highest quality settings.
> you name it.
I think Obamas birth certificate was among the victims. Some of the artifacts conspiracy theorists found on available images of it may have been caused by the JBIG2 compression algorithm of a Xerox scanner.
That's obviously not a good rule as stated, since the best way to follow it to run "rm -rf /" everything, which will give you zero attack surface and zero legacy support.
A more reasonable formulation is: legacy support should not always be prioritized over eliminating attack surface.
So if you want to minimise bugs and attack surface surely a.out is the format to stick with.
Earlier there was make and imake. Now there is make, imake, cmake, ninja, meson etc. My impression is that modern SW does everything what it can to increase the attack surface.
It could have some security bug, or it may complicate future work because changes break something in `binfmt_aout.c`, and then somebody has to figure out how to fix it and how to test that fix, which is probably a waste of time.
The cost of obscure functionality can be extremely high. Say your change made this bit stop compiling. Now you might manage to fix the compile error, but how do you know it still works properly? Now you need to figure out how to test it. A formerly simple change can suddenly balloon into seeking out the 5 people in the world who still want this, and making sure they're happy.
The point was that just because it's removed from the kernel doesn't mean it has to disappear if there is still interest to keep it up to date.
And recent developments have shown that ELF is not a barrier to getting old binaries working (the recent port of Word Perfect for Unix).
It didn't become the name of a format until Linux, and I think it really didn't get that name until ELF was introduced in Linux since they needed a way to distinguish the two formats.
> This is an abbreviated form of "assembler output", the filename of the output of Ken Thompson's PDP-7 assembler
It's not much code now, but the current state is untenable. It needs effort or removal.
I assume the patch writer is planning on making changes to those API's
This version of the app, maybe from 1995, was old enough to be in a.out format. Unfortunately I struggled to run it, because libc was in ELF format, not a.out.
Still, you have a point, the kernel code is not that much because the format is so simple. Arguably removing the code fails Linux's philosophy of not breaking userspace code.
I can't think of a reason why not.