Comment by lrvick
2 hours ago
We do sign our packages, but the threat model is to minimize the time it takes for users to not have to trust us.
It is critical to encourage many independent verifications that it be as fast as possible that someone can go from a clone of our tree of pure source code to the exact release hashes we publish.
Adding any binaries to that means someone that distrusts us must now go build those past releases as well, and if they rely on binaries, they must build those past past releases as well. This approach would make verification time go up dramatically every release.
You don't need to verify the chain of trust all the time, you can remember up to where you had trusted everything when you adopt your solution.
Also, while you can use the latest prebuilt as a stage0, you could also use any other prebuilt from earlier down the chain as a stage0 and still get the same stage2 binaries. This is the next trust checkpoint you have, and it should be fine to have multiple ways to get there too, one for quick iterative releases and one that is reusing the minimal amount of bootstrapped packages.
Or you just try to only upgrade your stage0 once in a while when extremely necessary and it would build your new stage2.
So many ways to optimize the system, it's a choice to refuse to reuse what was trusted yesterday in order to build the next stage.