Re: [Nix-dev] Sidestepping the community builds trust issue?

On Sat, 26 Dec 2015 09:07:38 +, Wout Mertens wrote: > If web-of-trust is the best solution, and the only blocker is build > reproducability, how about trying to classify > build differences? > > Each of the differences will have a reason, and either we can fix the build > to be

Re: [Nix-dev] Sidestepping the community builds trust issue?

It is case specific and involves fingerprinting each built file. For example, with prelinking you rewrite the elf headers, and to verify equivalence you simply set the linker instructions to 0 while calculating the file checksum. On Mon, Jan 4, 2016, 1:01 AM Tim Barbour

Re: [Nix-dev] Sidestepping the community builds trust issue?

On Sat, Dec 26, 2015 at 10:25 AM, Michael Raskin <7c6f4...@mail.ru> wrote: > >If web-of-trust is the best solution, and the only blocker is build > >reproducability, how about trying to classify build differences? > > > >Each of the differences will have a reason, and either we can fix the >

Re: [Nix-dev] Sidestepping the community builds trust issue?

On Sat, Dec 26, 2015 at 10:25 AM, Michael Raskin <7c6f4...@mail.ru> wrote: > >If web-of-trust is the best solution, and the only blocker is build > >reproducability, how about trying to classify build differences? I don't think that's the only blocker. Even if builds were reproducible today,

Re: [Nix-dev] Sidestepping the community builds trust issue?

If web-of-trust is the best solution, and the only blocker is build reproducability, how about trying to classify build differences? Each of the differences will have a reason, and either we can fix the build to be deterministic (e.g. timestamps, build paths), or we can classify a class of

Re: [Nix-dev] Sidestepping the community builds trust issue?

>If web-of-trust is the best solution, and the only blocker is build >reproducability, how about trying to classify build differences? > >Each of the differences will have a reason, and either we can fix the build >to be deterministic (e.g. timestamps, build paths), or we can classify a >class of

Re: [Nix-dev] Sidestepping the community builds trust issue?

>That would be great if we had deterministic build outputs, but we currently >have no easy way of determining whether a binary cache is corrupt or >whether a build was nondeterministic. Well, given five binary caches 4:1 and 2:2:1 hash distributions would give some information. And in some

Re: [Nix-dev] Sidestepping the community builds trust issue?

>A web-of-trust type approach is what I have previously heard discussed. In >the context of such an approach, I have three things to say in support of >my proposal. >3. In those first two points, I claim some advantage relative to a >web-of-trust style approach. However, both ideas are fully

Re: [Nix-dev] Sidestepping the community builds trust issue?

As Nicolas pointed out after we have presented our plan of attacking this problem (and as it was mentioned by Dan here), builds are only locally-reproducible. There is no guarantee that a build built by my machine and your machine will yield the same hash. It got me thinking - 1. Did anybody

Re: [Nix-dev] Sidestepping the community builds trust issue?

I have no opinion on this feature specifically, but re #3: avoiding a feature in order to keep things in a poor enough state so that users care about the issues you think they should care about is highly patronizing and a terrible way for developers to relate to users. It is incidentally

Re: [Nix-dev] Sidestepping the community builds trust issue?

I agree there is no conflict between your proposal and my suggestion. The reason I mentioned it is that I do not like the idea of relying on a single trusted party for security (to whic your proposal makes no difference, because the trusted party will control all build machines). If someone (use

[Nix-dev] Sidestepping the community builds trust issue?

I've seen several conversations centered on how to enable private individuals and/or companies to contribute to publicly available binary caches, without requiring end users to explicitly trust those private entities. The main problem, for which I'm not aware of a complete solution, is that there