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

[Alexander Kjeldaas]

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
> build
> >to be deterministic (e.g. timestamps, build paths), or we can classify a
> >class of changes as equivalent (e.g. optimalizations resulting in
> >equivalent code, prelinking).
>
> Do we want to do something about Profile Guided Optimisation, for
> example? I think GCC builds itself with PGO after bootstrapping, and
> I don't know what other packages use some amount of unreproducible PGO.
>
>
PGO is in theory reproducible, it just has another input which is the
profile data.  The question is whether it is possible to attack an
otherwise trusted build using fake profile input.

If the profile input is not a usable attack vector, then all that is needed
is consensus on which input to use for a PGO compilation.  This is easier
than the trust issue.

Alexander
___
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?

[Anders Papitto]

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, there are still some complexities around trust. What's to stop me
from spinning up a dozen ec2 instances, each of which provides the same,
bitwise identical, poisoned build of some obscure package that no one else
will bother to verify? And probably a million other such edge cases.
Probably it can be solved, but until I see a complete, detailed solution I
don't view this problem as trivial. Also, I'm not aware of any prior art -
much more security-conscious distros, like Debian, rely on
centrally-administered build farms.

Independently, anyone who is discussing build reproducibility needs to be
familiar with the Debian Reproducible Builds Initiative (
https://wiki.debian.org/ReproducibleBuilds), which is addressing exactly
this problem, and has moved beyond theory into extensive implementation.

My view is that any system being designed for the long term (say, 2+ years
from now) can rely on almost all software being amenable to bitwise
reproducible builds, by piggybacking on the Debian effort (because they are
putting in the man-hours to fix upstreams, not only doing debian-specific
hacks). However for any improvement that we'd like to make in the near term
(days, weeks, months), I don't think such a dependency is reasonable.

- Anders

On Sat, Dec 26, 2015 at 2:59 AM Alexander Kjeldaas 
wrote:

> 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
>> build
>> >to be deterministic (e.g. timestamps, build paths), or we can classify a
>> >class of changes as equivalent (e.g. optimalizations resulting in
>> >equivalent code, prelinking).
>>
>> Do we want to do something about Profile Guided Optimisation, for
>> example? I think GCC builds itself with PGO after bootstrapping, and
>> I don't know what other packages use some amount of unreproducible PGO.
>>
>>
> PGO is in theory reproducible, it just has another input which is the
> profile data.  The question is whether it is possible to attack an
> otherwise trusted build using fake profile input.
>
> If the profile input is not a usable attack vector, then all that is
> needed is consensus on which input to use for a PGO compilation.  This is
> easier than the trust issue.
>
> Alexander
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Disabling patchelf on ARM

[Jookia]

Hey there,

I've been working for a few months on getting a Novena port of NixOS running.
The overall Nix infrastructure works, though I still have a ton of issues to
solve before publishing any patches required on a git repository (they probably
won't be merged in to nixpkgs anyway.)

A problem I've been dealing with is mysterious segmentation faults affecting the
system along with bugs that aren't present in Debian on the same system.
patchelf has been the culprit for quite a few of them and upstream doesn't seem
to be working on fixing this.

I haven't looked at this too deeply, but I'm wondering: Is there a way to
disable patchelf to stop it corrupting my binaries? I'm not running any nonfree
software so I'm not too worried about working with unchangeable code.

Cheers,
Jookia.
___
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?

[Wout Mertens]

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 changes as equivalent (e.g. optimalizations resulting in
equivalent code, prelinking).

It could very well be that we cannot automatically determine if a set of
builds is equivalent, and then the build will simply have to be done
locally instead of downloaded.

On Fri, Dec 25, 2015, 9:48 PM Tim Barbour  wrote:

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

Wout.
(typed on mobile, excuse terseness)
___
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]

>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 changes as equivalent (e.g. optimalizations resulting in
>equivalent code, prelinking).

Do we want to do something about Profile Guided Optimisation, for
example? I think GCC builds itself with PGO after bootstrapping, and 
I don't know what other packages use some amount of unreproducible PGO.



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