melekes
commented
6 years ago It's more secure to have many signers, for that mitigates the risk of getting the server hacked. But it doesn't mitigate the risk of getting the dist-building code itself hacked.
that was the original plan
A partial solution is to not specify/automate certain things which could be fixed manually. For example, the dist script could choose not to specify a docker image to build under, but rather inherit the environment from the caller.
agree. but https://github.com/tendermint/devdoc is public (you don't have to be Sherlock Holmes to figure out what image devs are using right now). make it private?
A "distribution" event is a singular event with high ramifications (e.g. distributing a hacked binary will affect many people), we might as well take extra precautions while releasing a dist.
We could make the dist, signing, and releasing process automated, and the obvious attack is to hack the signing server or the code that handles the signing.
It's more secure to have many signers, for that mitigates the risk of getting the server hacked. But it doesn't mitigate the risk of getting the dist-building code itself hacked.
A partial solution is to not specify/automate certain things which could be fixed manually. For example, the dist script could choose not to specify a docker image to build under, but rather inherit the environment from the caller.
So the dist-builders are required to find an environment to build in, whether that be a Docker container or something else. This manual setup acts as a kind of fuzzer. There are many configurations that should lead to the same build, such as using Golang version 1.9.x
If we find a discrepancy, it might be because we found a vulnerability, so instead of getting annoyed, we should be thankful and learn what caused the unintended non-determinism, and isolate it, but only it.
I should figure out a way to propose things without using the word "should". I could say "could"...