This approach
let's delete autoconf-generated cruft from upstream projects and
regenerate it in %prep
To me sounds woefully inappropriate for the task at hand. You remove a single attack
vector while completely overlooking that many of your maintainers don't have the
qualifications to vet the included code even if it's autoconf-cruft free.
AFAIK, the bad code discovered in XZ was on its way to the GIT repo, could have been
included in a slightly different way and if not for the wonderful discovery by the
Microsoft software engineer of all people, we'd be dealing with a whole much more
terrible outcome.
The source code must be vetted. In a perfect world, considering the entire source code is
available, an API calls map for each release could be built/extracted, so that whenever a
new version is published by the upstream, a new map for the new release could easily show
at least all the new API calls that the project now uses to easily discover whether new
features correspond to what the project maintainer published in their changelog. Probably
another "anti-freedom" proposal.
And of course, would be great to employ all the methods of automated software
verification, like static analysis, sandboxing, fuzzying, etc. I'm just dreaming.
Let's pretend this incident is entirely about autoconf stuff, and not about a software
project being hijacked by hostile actors. And of course, you're absolutely sure this
hasn't already happened in other widely used projects and will never happen again.
Again, sorry for intervening. I just freaked out when I realized my Linux box might have
been compromised after almost believing in the persistent myth of "multiple
eyes" (five?) scanning open source software for malware. It's not been the case,
the entire proposal that we are discussing here is not talking about it either. I'm
confused.
Regards,
Artem