Sirius <sir...@trudheim.com> writes: > Would throwing away these unmodified (?) macros packaged projects may be > carrying for hysterical raisins in favour of just using the autoconf > native macros reduce the attack-surface a potential malicious actor > would have at their disposal, or would it simply be a "putting all eggs > in one basket" and just make things worse? And by how much vis-a-vis the > effort to do it?
Most of the macros of this type are not from Autoconf. They're from either gnulib or the Autoconf Archive. In both cases, blindly upgrading to a newer upstream version may break things, I believe. I'm not as sure with gnulib, but the Autoconf Archive is a huge collection of things with varying quality and does not necessarily have any guarantees about APIs. > I think that what I am trying to get at is this: is there low-hanging > fruit that for minimal effort would disproportionately improve things > from a security perspective. (I have an inkling that this is a question > that every distribution is wrestling with today.) I think the right way to think about this is to say that the Autoconf ecosystem is rife with embedded code copies and, because the normal way of using this code is to make a copy, is also somewhat lax about making breaking changes since the expectation is that you only update during your release process when you can fix up any changes. (That code is also notoriously hard to read, both because M4 is a language with fairly noisy syntax and because the only tools assumed to be available in the output scripts is a very minimal Bourne shell and standard POSIX shell utilities, so there's a lot of the type of programming that only shell aficionados can love. That was the problem with detecting this backdoor: the sort of chain of tr and eval and whatnot that injected the backdoor is what, e.g., all of Libtool looks like, at least on a first superficial glance.) I know all this adds up to "why are we using this stuff anyway," but the amount of hard-won portability knowledge that's baked into these tools is IMMENSE, and while probably 75% of it is now irrelevant because the systems that needed it are long-dead, no one can agree on what 75% that is or figure out which useful 25% to extract. And rewriting it in some other programming language is daunting and feels like churn rather than progress. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
