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

[Anders Papitto]

On Sat, Dec 26, 2015 at 10:25 AM, Michael Raskin <7c6f434c at 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 <ak at formalprivacy.com>
wrote:

> On Sat, Dec 26, 2015 at 10:25 AM, Michael Raskin <7c6f434c at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20151226/202f90cf/attachment.html