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.devran...@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 <s...@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.devran...@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.devran...@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 <s...@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.devran...@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.devran...@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 <s...@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.devran...@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.
>> >>> >>> >

Reply via email to