[Discussion] Upgrade rustc to 1.20.0 + future upgrade requirements. about rust-bitcoin

[real-or-random]

Is there a good reason not to jump to 1.24.1 immediately then?

[real-or-random]

I was under impression that once you do a bootstraping like this once, and then compile the compiler source code with the bootstrapped compiler binary and then with the original compiler binary, and they produce the same output, you've proven that the original compiler at a given checksum does not contain any backdoors, and can be used from now on as a starting point. Sorry if I'm terribly mistaken here. :)

I'm under the same impression.

[sgeisler]

@real-or-random afaik bootstrapping rustc has to begin with 1.19 or earlier versions because that's the latest version supported by mrustc. Every version increase over that introduces one more step from there.

[real-or-random]

I didn't follow the discussion in IRC. Why is bootstrapping so much more secure?

[dpc]

@sgeisler Isn't the whole process automatable, and that will have to be done eventually anyway? I mean - eventually even newer version will be a requirement. Also, does it even have to be repeated ever again?

I was under impression that once you do a bootstraping like this once, and then compile the compiler source code with the bootstrapped compiler binary and then with the original compiler binary, and they produce the same output, you've proven that the original compiler at a given checksum does not contain any backdoors, and can be used from now on as a starting point. Sorry if I'm terribly mistaken here. :)

Seems like GUIX team just went to 1.28.0: https://www.gnu.org/software/guix/blog/2018/bootstrapping-rust/

[dpc]

@real-or-random https://www.schneier.com/blog/archives/2006/01/countering_trus.html is my understanding.

[dongcarl]

The real thing that I want to discuss is how the whole process should look like. Without a deterministic build of the compiler, we need to trust someone to build the compiler. Who do we trust?

This might be less of a problem because we don't release binaries, so any malicious tampering would only cause discrepancies between the Travis test results.

My naive plan that's meant to draw constructive criticism:

1. I build 1.19.0, then 1.20.0
2. I upload the binaries somewhere
3. I modify travis to pull down the binaries instead of using its own rust compiler

[dongcarl]

@dpc You're right. But there are usually many complications in this process, and the original author of the diverse double compiling paper, when trying to demonstrate the process, even had to patch compilers.

Given that we're doing one-off DDC, I guess:

1. Agree on which rustc binary to use
2. DDC check on said rustc binary
3. If passed, modify travis to use that binary instead of using its own rust compiler

[real-or-random]

For what it's worth, there is quite some progress on a mrust brach targeting 1.29, see https://github.com/thepowersgang/mrustc/commits/nightly-1.29 and thepowersgang/mrustc#95 .

[dongcarl]

@real-or-random Yes. However, we are somewhat limited by what debian packages under stable. I think it makes sense that for a major distribution like debian, people should be able to install rustc and compile rust-bitcoin with no problems. This means we can only do <= 1.24.1.

[real-or-random]

Hm, yes, I know. I somehow assumed that this branch of mrustc will then also be able to compile rustc 1.24.1. But I see that this assumption is probably not justified...

[dongcarl]

I've bumped the version to 1.20.0 here: #210

I believe we should use this thread to discuss how we want to do the process. Perhaps we should wait until deterministic builds are easy with rustc?

[real-or-random]

In general, it may be a good idea to bump shortly after a Debian release. This is rare enough, and we then can decide which version we want.

[dongcarl]

Closed by #210