I think this can be made much more difficult by enforcing a policy of open builds for open source.
It shouldn't be possible to inject build files from a local machine.
All build assets should come from the source repository.
Artifacts should come from Github Actions or some other tool that has a clear specification of where all inputs came from.
Perhaps Github could play a role in helping to automate any inconveniences here.
Yes the whole "let's take a mystery meat tarball from a repo that isn't the project repo" seems suspect.
Github+ even has a scheme for signing artifacts such that you have some level of trust they came from inside their Actions system, derived from some git commit. This would allow the benefits of a modular build for a large product like a distro, while preserving a chain of trust in its component parts.
+Not advocating a dependency on Github per se -- the same sort of artifact attestation scheme could be implemented elsewhere.
I think that trust needs to be 'pushed deeper' than that so to speak. While this would be an improvement, what happens if there is a malicious actor at Github? This may be unlikely, but would be even harder to detect since so much of the pipeline would be proprietary.
Ideally, we would have a mechanism to verify that a given build _matches_ the source for a release. Then it wouldn't matter where it was built, we would be able to independently verify nothing funky happened.
Vendor independent build providence is certainly the long-term goal. In the immediate-term moving away from mystery tarballs towards version control gets us a step closer.
One of the best things about Golang is that packages are shared direct via source repositories (Github) rather than a package repository containing mystery tarballs. I understand the appeal of package repositories, but without proper security constraints it's a security disaster waiting to happen.
Wasn’t the payload in a blob in the tests, which is in the source repo? If you were to clone the repo then build from source, you’d have the backdoor, right? Surely distros aren’t using binaries sent by maintainers
No. The payload was in the checked in test files, but the test files were inert. They were only activated by the tarball having different build files than the repository (or rather, different build files than would be generated by autotools for the repository), which extracted the payload from the test files and injected it into the output binary.
