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

[Michael Raskin]

>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 sense both packages and caches would accumulate reputations.



___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Michael Raskin]

>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 compatible.
>Precisely because my suggestion makes no changes to the current trust
>model, it would be just as easy (or difficult) to add in a web-of-trust
>style mechanism afterwards. However, of the two, it seems to me that this
>idea has significantly lower barriers to full implementation in the short
>term, which is why I bring it up.

I think that web-of-trust model allows to get some benefits even when 
Nix builds are only a part of the computer's load. In that sense it gets
lower barrier of entry for contributors. But maybe there are enough 
teams who do have full-time Nix build slaves…



___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Jonn Mostovoy]

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 measure deviation in output hashes we'll face if we
are to try to "simply" distribute the builds?
 2. Do you think that asking companies / individuals to contribute
standard hardware with standard nixos configuration would reduce the
deviation in output hashes?

Regarding proposed approach -

 1. Priorities in distributed systems make Joe Armstrong sad.
 2. We're increasing distribution at a cost of bigger decentralization.
 3. Even if this workaround works, it's still a hack. It will lead to
community not perceiving what is a problem as a problem. I say we
should avoid success at all costs and deliver the correct solution to
the problem of distributed builds.
—
Kindest regards,
¬Σ


On Fri, Dec 25, 2015 at 10:57 AM, Michael Raskin <7c6f4...@mail.ru> wrote:
>>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 compatible.
>>Precisely because my suggestion makes no changes to the current trust
>>model, it would be just as easy (or difficult) to add in a web-of-trust
>>style mechanism afterwards. However, of the two, it seems to me that this
>>idea has significantly lower barriers to full implementation in the short
>>term, which is why I bring it up.
>
> I think that web-of-trust model allows to get some benefits even when
> Nix builds are only a part of the computer's load. In that sense it gets
> lower barrier of entry for contributors. But maybe there are enough
> teams who do have full-time Nix build slaves…
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Shea Levy]

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 ridiculous to think 
that this particular community will ever stop caring about solving this 
particular problem, but more importantly if you can't convince users to care 
about something without artificially limiting the usefulness of their tools 
then perhaps that thing is not actually worth caring about.

> On Dec 25, 2015, at 6:21 AM, Jonn Mostovoy  wrote:
> 
> 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 measure deviation in output hashes we'll face if we
> are to try to "simply" distribute the builds?
> 2. Do you think that asking companies / individuals to contribute
> standard hardware with standard nixos configuration would reduce the
> deviation in output hashes?
> 
> Regarding proposed approach -
> 
> 1. Priorities in distributed systems make Joe Armstrong sad.
> 2. We're increasing distribution at a cost of bigger decentralization.
> 3. Even if this workaround works, it's still a hack. It will lead to
> community not perceiving what is a problem as a problem. I say we
> should avoid success at all costs and deliver the correct solution to
> the problem of distributed builds.
> —
> Kindest regards,
> ¬Σ
> 
> 
> On Fri, Dec 25, 2015 at 10:57 AM, Michael Raskin <7c6f4...@mail.ru> wrote:
>>> 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 compatible.
>>> Precisely because my suggestion makes no changes to the current trust
>>> model, it would be just as easy (or difficult) to add in a web-of-trust
>>> style mechanism afterwards. However, of the two, it seems to me that this
>>> idea has significantly lower barriers to full implementation in the short
>>> term, which is why I bring it up.
>> 
>> I think that web-of-trust model allows to get some benefits even when
>> Nix builds are only a part of the computer's load. In that sense it gets
>> lower barrier of entry for contributors. But maybe there are enough
>> teams who do have full-time Nix build slaves…
>> 
>> 
>> 
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Tim Barbour]

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 your imagination) wanted to be able to gain
access to any nixos machine, they would be tempted to compromise the
centrally controlled builds.

Therefore I think we should encourage people to run build systems,
whether centrally controlled or not.

Tim
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev