definitely any binary file checked in must be suspect after this event.
Packagers like deb and rpm (I work for Red Hat and have done some rpm packaging) should modify their build processes so that while they may run test suites ahead of time which use binary files, the post testing build phase should start from zero with all binary files fully removed from an untouched source download. There can be steps that attempt to build from a tar distro vs a GitHub source tree and compare. There's lots of ways a lot more caution can be provided around binary files, and I'm talking about downstream packagers for which there are a lot of resources to work on this (at Red Hat we're paid for this kind of work).
That's a good point, I guess what you want is that the build artifacts are produced and archived (or at least made read-only) before the test suite runs, to avoid output cross-contamination from the test phase.
I have only a cursory experience with rpm builds, but with the normal debhelper process that should be quite easy: just switch the order of the dh_install and dh_auto_test targets, and then make sure the debian/ directory is read-only before running the tests.
Packagers like deb and rpm (I work for Red Hat and have done some rpm packaging) should modify their build processes so that while they may run test suites ahead of time which use binary files, the post testing build phase should start from zero with all binary files fully removed from an untouched source download. There can be steps that attempt to build from a tar distro vs a GitHub source tree and compare. There's lots of ways a lot more caution can be provided around binary files, and I'm talking about downstream packagers for which there are a lot of resources to work on this (at Red Hat we're paid for this kind of work).