On Sat, Dec 26, 2015 at 10:25 AM, Michael Raskin <[email protected]> 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 <[email protected]> wrote: > On Sat, Dec 26, 2015 at 10:25 AM, Michael Raskin <[email protected]> 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 [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
