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

[Devrandom]

Sounds good.

Sorry to hear you were sick.  Vitamin D FTW.

On Mon, Jan 8, 2018 at 10:40 AM Sean Bowe <sean at z.cash> wrote:

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