Automatically auditing tarballs?

Some of the source code backdooring attempts I know (Linux backdoor from November 2003, ProFTPD and now XZ) that don't look like mistakes (these are not memory safety bugs that are easy to make) were not done in the version control system but instead directly on tarballs.

Using the version control system directly in packages is probably not the answer though as this is not always a drop-in replacement for tarballs.

For instance many git repositories don't sign commits while tarballs are often signed, and if not, the checksum of a tarball is something relatively simple that give very strong guarantees against hosters somewhat subverting the tarball and making it pass the check.

As I understand git also has issues, for instance enabling enabling fsckObjects is not always practical as many projects (including Linux) require skiplists. And if I understood right, without that the hoster of the repository can somewhat subvert the commits in a way that still pass all the integrity of the checks.

Guix has tooling to create tarballs from git (see "Supporting long-term reproducibility" in https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/) however I'm unsure if it's also used to somewhat automatically audit tarballs, but It can at least be re-used to least detect if a given git commit correspond to a given tarball with some code as the functionality to do that is there.

If this is also used for security somehow, to catch cases where the tarball was equal to the git release + some metadata and started having extra code, and/or if we add such functionality to most distributions, we could at least catch regressions and new issues and make backdooring (some) tarballs more difficult.

As for cases where the tarball differs, maybe a similar approach could work too: warnings about the extra files or a diff could be reported to the packagers and enable the packagers to fix that by either ignoring the warning or by removing the differences somehow (rm -f configure [...] && autoreconf -vfi && [...]) .

This is probably does not work well for all distributions as some have very simplistic build systems[1] that don't allow to modify the way all autotools builds or git fetch are done in a single place, but it's not necessarily a big issue as doing that in the other distributions still increase the probability of catching issues and avoiding it for the ones with simplistic build systems.

[1] Like every approach, they have advantages and disadvantages. One of the advantage of simplistic build systems is that making packages with these is way easier, and so it enables more people to contribute and/or to be empowered to package what they need, modify packages, etc. The disadvantage is that adding an option to most packages, or reusing the package information globally is time consuming.