I think the author hasn’t accurately described the workflow where reproducible builds are used. Here’s my attempt. There are three entities: 1. The vendor, w

I think the author hasn’t accurately described the workflow where reproducible builds are used. Here’s my attempt. There are three entities: 1. The vendor, who creates and _distributes_ a product, which may include software, to the end user 2. The end user, who receives the product from the vendor, operates the product, and trusts one or more verifiers to correctly certify the product according to some standard that the user desires 3. Verifiers, who receive proprietary access to the vendor’s product (e.g. source code) and check that the product meets a set of standards and assert that fact to the users Note that verifiers are NOT in the job of distributing products to users. That’s a hard job and it seems understandable to me if verifiers don’t want that job. Reproducible builds help link a specific version of source code that a verifier certified to a specific product being operated by a user. Without it, the user trusts the vendor much more than with it. Yes it adds brittleness and delay (see FIPS 140 certification). These are use case specific trade offs that only users can judge. In the case where some facts about the source code can be formally verified, reproducible builds support that trust relationship much better. I might go so far as to say that reproducible builds are essential for trusting formal verification. You can also imagine a software supply chain that includes more steps than a simple vendor -> user relationship. Much of the proprietary software used today include libraries from third party vendors. There are integrators that add their own special sauce. The supply chain looks more like: vendor -> vendor -> ... -> vendor -> end user. Imagine each vendor has their own set of verifiers responsible for certifying that vendor’s output.