[zapps-wg] Trusted Rust build process is ready for evaluation

Sean Bowe sean at z.cash
Mon Jan 8 13:40:08 EST 2018


Hi,

I've been quite busy with holidays, work and being sick. :( I'd like
to get around to writing some instructions for the ceremony that
encourage people to consider using your work, so reviewing it is one
of my priorities. I'll find a time to do that soon.

Sean

On Mon, Jan 8, 2018 at 11:27 AM, Devrandom <c1.devrandom at niftybox.net> wrote:
> Sean,
>
> How is it going with the evaluation?
>
> I'm concerned because rounds are continuing, yet participants are using
> versions of Rust of unknown provenance.  In fact, everybody might be using
> Rust with a common ancestor compiler, so that we have a single point of
> failure.
>
>
> On Thu, Dec 7, 2017 at 11:10 AM Devrandom <c1.devrandom at niftybox.net> wrote:
>>
>> It looks like the result is pretty far from deterministic.  In fact, I see
>> 20,000+ lines of difference in diffoscope.
>>
>> So it looks like each participant will have to build their own toolchain.
>>
>>
>> On Tue, Dec 5, 2017 at 4:44 PM Sean Bowe <sean at z.cash> wrote:
>>>
>>> That would be nice!
>>>
>>> What other obstacles are there for fully deterministic builds? It
>>> seems like it would be a good idea to toss a few features in (like
>>> that one) and make some kind of "release" binaries for people to use
>>> which have been scrutinized and built in this reproducible way.
>>>
>>> I hopefully will run into some time soon where I can audit the changes
>>> you made to the code and dependencies, play with the build, do
>>> comparisons and so forth. This is exciting!
>>>
>>> Sean
>>>
>>> On Tue, Dec 5, 2017 at 5:20 PM, Devrandom <c1.devrandom at niftybox.net>
>>> wrote:
>>> > Verification passed (in fact, new_challenge was identical).
>>> >
>>> > BTW, would be nice if `compute` had a flag to only take entropy from
>>> > STDIN,
>>> > so that we can check for any differences in the response.
>>> >
>>> > On Tue, Dec 5, 2017 at 12:48 PM Devrandom <c1.devrandom at niftybox.net>
>>> > wrote:
>>> >>
>>> >> Thank you.  Will do the verification shortly.
>>> >>
>>> >> Also, I've updated the instructions in
>>> >>
>>> >> https://github.com/devrandom/powersoftau/wiki/Trusted-build-instructions-via-mrustc
>>> >> to use the cargo built by mrustc.  This required vendoring of the
>>> >> dependencies.
>>> >>
>>> >>
>>> >> On Tue, Dec 5, 2017 at 11:24 AM Sean Bowe <sean at z.cash> wrote:
>>> >>>
>>> >>> Excellent work! :)
>>> >>>
>>> >>> new, compute, verify_transform is a good demonstration. I would
>>> >>> verify_transform with a binary compiled with the normal Rust compiler
>>> >>> to double-check.
>>> >>>
>>> >>> Sean
>>> >>>
>>> >>> On Tue, Dec 5, 2017 at 11:59 AM, Devrandom
>>> >>> <c1.devrandom at niftybox.net>
>>> >>> wrote:
>>> >>> > Hi all,
>>> >>> >
>>> >>> > I was able to build rustc completely from sources.  This means no
>>> >>> > network
>>> >>> > access during the build and without any Rust distributed binaries.
>>> >>> >
>>> >>> > The steps are here:
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > https://github.com/devrandom/powersoftau/wiki/Trusted-build-instructions-via-mrustc
>>> >>> >
>>> >>> > I'm still looking into building a cargo binary that supports TLS,
>>> >>> > to
>>> >>> > eliminate the need to download it for building powersoftau itself.
>>> >>> > Worst
>>> >>> > case we can use a shell script.
>>> >>> >
>>> >>> > Would like to merge https://github.com/ebfull/pairing/pull/72 so
>>> >>> > that
>>> >>> > we
>>> >>> > don't have to maintain a separate patch for Rust 1.19
>>> >>> > compatibility.
>>> >>> >
>>> >>> > Sean, what is the best method of validating that the generated
>>> >>> > binary
>>> >>> > works
>>> >>> > correctly?  Just use "new", then "compute" and then
>>> >>> > "verify_transform"?
>>> >>> >
>>> >>> > Also, I found that the generated binary is *very* different from
>>> >>> > the
>>> >>> > one
>>> >>> > generated by the downloadable Rust compiler.  This is somewhat
>>> >>> > worrisome,
>>> >>> > although it doesn't affect us if we use the mrustc path.  Will
>>> >>> > spend a
>>> >>> > bit
>>> >>> > more time to get to the bottom of it.
>>> >>> >



More information about the zapps-wg mailing list