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 -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
