Unfortunately, it is currently not possible to automatically verify a distribution release against its source code. There are, however, intermediate results which can be used to some extent; the Reproducible Builds project is the main driver.
Reproducibility is the ability, given the same inputs and the same tools, to produce the same output artifacts. Various projects participating in the Reproducible Builds effort thus allow some level of reproducibility; for example:
- many Debian packages are reproducible, so given the same source package, and the same build environment (compiler, build dependencies etc.), you will get bit-for-bit identical packages;
- Debian’s official Docker images are reproducible, so given the same reference packages (not source code), and the same build tools, you will get bit-for-bit identical root file systems.
End-user verification of the artifacts produced above isn’t yet possible, notably because the files which record the build environment aren’t published (as far as I’m aware). They are preserved though, so at some point this will become possible.
I don’t think any “large” distribution supports reproducibility all the way from the source code to the distribution media (ISO etc.), let alone verification. There are a number of obstacles in the way:
- not all software can be built reproducibly, yet;
- reproducible artifacts embed “knowledge” of their build environment, and that is fluid over the duration of a distribution’s preparation (so verifying a distribution would involve reconstructing its history);
and probably others I’m not thinking of just now. Tails does publish fully-reproducible distribution media, so this is technically possible, but it requires the distribution to be made reproducible; a distribution can’t be verified by external actors if it isn’t published in a reproducible manner. (This doesn’t stop external audits from existing, and sometimes being useful.)
Look at the various projects referenced on the Reproducible Builds site, some of them are focused on making all this simpler; see for example in-toto. The Reproducible Builds project itself publishes a number of tools which can help produce and analyse reproducible artifacts.
One point in your question is already largely addressed, even without reproducibility and verifiability:
how can I be sure that the maintainers haven't slipped in something nefarious outside of the public code base during the build?
Most distributions (I don’t know about Deepin) only publish binary artifacts which have been built on their own build infrastructure, so maintainers can’t slip anything in outside of the public code base (public as in, recorded with the artifact). This doesn’t remove the trust you implicitly place in the distribution itself, which is your main concern here, but at least it removes individual maintainers’ ability to publish malicious artifacts without also publishing the corresponding source code.
See also Ken Thompson’s classic “Reflections on trusting trust”, and subsequent research on the topic of trusting compilers; and the following questions here: