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

Devrandom c1.devrandom at niftybox.net
Mon Jan 8 15:48:36 EST 2018


Will add `--frozen`.

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

> One quick comment from glancing: use --frozen in your invocation of
> cargo to prohibit network access and sort of "test" that the
> dependencies were vendored correctly. I was pretty satisfied when
> looking at trust-rust before. Obviously the non-determinism sucks, but
> given how much the rust compiler uses randomly seeded hashmaps that's
> where I would look. :)
>
> Sean
>
> On Mon, Jan 8, 2018 at 11:46 AM, Devrandom <c1.devrandom at niftybox.net>
> wrote:
> > 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.
> >> >>> >>> >
>



More information about the zapps-wg mailing list