Skip to content
This repository has been archived by the owner on Feb 12, 2021. It is now read-only.

Dist fuzzing - dist process should not be so deterministic. #47

Open
jaekwon opened this issue Jan 12, 2018 · 1 comment
Open

Dist fuzzing - dist process should not be so deterministic. #47

jaekwon opened this issue Jan 12, 2018 · 1 comment
Assignees
Labels

Comments

@jaekwon
Copy link
Contributor

jaekwon commented Jan 12, 2018

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"...

@jaekwon jaekwon changed the title dist process should not be so deterministic. Dist fuzzing - dist process should not be so deterministic. Jan 16, 2018
@melekes
Copy link
Contributor

melekes commented Jan 17, 2018

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants