Earlier quoted context omitted.
I don't know what they're planning to do, but we could need only a few parties doing the verifications. If a build yields the wrong binary then the release is flagged and nobody gets it. Apt should check against the expected results. Many things could go wrong with this (mainly attacks on the expected results db, it should be replicated) but the idea should work.
The thing is if the threat is any machine on the publisher side being infected, then it sorts of need to be verified by the consumer of the software, a bit like compiling a checksum when you download software.
- (N-1) machines build a new Debian package.
- The (N-1) results are fetched by the fourth party.
- The Nth party checks whether the build results are identical.
- The Nth party signs the result with GPG on a machine that is not connected.
- The signed package is distributed.
An attacker would need to compromise either: (1) N-1 build machines; (2) the offline machine used for signing packages; or (3) the upstream source.
I consider (3) to be the most serious thread. But in this scenario, only the distribution packagers need to inspect the source changes. In the common scenario where you download from a vendor (e.g. the Transmission or CCleaner website), every user has to inspect a binary blob.
Another possibility would be to have strong sandboxing for applications. An application could still participate in DDoS attacks, etc. But it would at least not encrypt/destroy your data.
tl;dr: reproducible builds are an extremely important development and Debian (and other distributions participating in this initiative) should be commended for their work!