Something I've wondered about wrt this debacle: presumably the smart part of xz was the compression algorithm. I'm guessing but that's probably less than 500 lines of code. The rest is plumbing to do with running the algorithm in a CLI utility, on various different OSes, on different architectures, as a library, and so on. All that stuff is at some level of abstraction the same for all things that do bulk processing on bytes of data. Therefore perhaps we should think about a scheme where the boilerplate-ish stuff is all in some framework that is well funded with people to ensure it doesn't have cutout maintainers injecting backdoors, and is re-used for hundreds of bulk-data-processing utilities; and the clever part would then be a few hundred lines of code that's easy to review, and actually probably never needs to change. Like...a separation of concerns.
we were discussing this on the IRC. Imagine spinning up a thread, then running a bsd style pledge(2) on it to call liblzma. Kinda janky but it would work. Another option would be to just go out and call the xz util and not rely on a library to do so. That process can be locked down with pledge to only have stdin/stdout. That's all you need.
So, like UNIX does have this plumbing, its just that reaching for libraries and tight integration has been the pursuit of Lennart Poopering and his clan for years.
