[Nix-dev] Deterministic(bit-perfect) Builds
Hi Nixers, This is what I have achieved so far: Regular c(++) libs/apps mostly had impurities due to timestamps in static libraries and man pages. Both have been largerly eliminated if you override stdenv = deterministicStdenv for the specific package. Tested with ncurses and geoip. Python packages had troubles with timestamps inside pyc files. I have patched python to put zero timestamps instead if DETERMINISTIC_BUILD env var is set. I have patched 2 pieces of code either of which can be used to compile pyc files. Tested with argparse. I think I saw a package which has nevertheless managed to inject the timestamps, so maybe there's a 3rd way of compiling which also needs patching. Ruby gems had these impurities: * documentation generators (rdoc and ri) left something like a log or cache file with timestamps, the files are now deleted. * the default documentation template contained an item for generation datetime which was removed. * building a gem with native bindings generated a log which is wiped if the build succeeds. Probably should rework this to provide vanilla ruby functionality unless DETERMINISTIC_BUILD is set and maybe unset this var if NIX_DEBUG is set? Perl doesn't seem to have any systematic source of impurities. Ocaml seems to only have troubles due to timestamps in static libs so deterministicStdenv should solve it. Haskell is hopeless: http://hackage.haskell.org/trac/ghc/ticket/4012 Although it's quite possible that we can still figure out the source of ghc entropy and deal with it. Unstripped binaries: may be contaminated by build-id. Can be avoided either by passing ld --build-id=none param or careful stripping. Needs testing. Luckily this is a very small subset of packages. Next steps: * actually rebuild the whole system using deterministicStdenv * try to make nixos system tarball or minimal iso bit-perfect. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
On 06/25/2013 10:45 AM, phree...@yandex.ru wrote: This is what I have achieved so far: Sounds nice. Wouldn't it be more certain/universal to LD_PRELOAD or something to achieve that the system time always looks the same to any build-time tool? (e.g. UNIX time =0) Unstripped binaries: may be contaminated by build-id. Can be avoided either by passing ld --build-id=none param or careful stripping. Needs testing. Luckily this is a very small subset of packages. I looked at man ld and I think we rather want --build-id=sha1 as it's explicitly stated that the ID is uniquely determined by the output. Vlada smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
В письме от Вторник 25 июня 2013 10:57:06 пользователь Vladimír Čunát написал: On 06/25/2013 10:45 AM, phree...@yandex.ru wrote: This is what I have achieved so far: Sounds nice. Wouldn't it be more certain/universal to LD_PRELOAD or something to achieve that the system time always looks the same to any build-time tool? (e.g. UNIX time =0) This is a bit platform-specific and there may be other gotchas like getting the mtime using stat instead of querying system time. Other impurities in static libs are uid/gid of the file. But sanitizing build inputs in general is a very interesting topic which has practical applications and deserves a separate discussion. Unstripped binaries: may be contaminated by build-id. Can be avoided either by passing ld --build-id=none param or careful stripping. Needs testing. Luckily this is a very small subset of packages. I looked at man ld and I think we rather want --build-id=sha1 as it's explicitly stated that the ID is uniquely determined by the output. I haven't checked for sure but vandenoever's tests seem to indicate that the default build id is in fact sha1 and it depends on the build dir :( ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
Hi, I'm not a big contributor yet, but I just wanted to say to the nix-dev community: thanks for the work. Especially the Haskell package managers. A purely functional language and a purely functional package manager. On Tue, Jun 25, 2013 at 5:57 PM, Vladimír Čunát vcu...@gmail.com wrote: On 06/25/2013 10:45 AM, phree...@yandex.ru wrote: This is what I have achieved so far: Sounds nice. Wouldn't it be more certain/universal to LD_PRELOAD or something to achieve that the system time always looks the same to any build-time tool? (e.g. UNIX time =0) Unstripped binaries: may be contaminated by build-id. Can be avoided either by passing ld --build-id=none param or careful stripping. Needs testing. Luckily this is a very small subset of packages. I looked at man ld and I think we rather want --build-id=sha1 as it's explicitly stated that the ID is uniquely determined by the output. Vlada ___ 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] Deterministic(bit-perfect) Builds
On 06/25/2013 11:43 AM, phree...@yandex.ru wrote: Wouldn't it be more certain/universal to LD_PRELOAD or something to achieve that the system time always looks the same to any build-time tool? (e.g. UNIX time =0) This is a bit platform-specific and there may be other gotchas like getting the mtime using stat instead of querying system time. Other impurities in static libs are uid/gid of the file. I would think that the file timestamps also originate from system time so we could kill more birds with one stone... but I don't have a clue whether/how such a sandbox can be done easily (in Linux; I assume our main target for purity is Linux, the others are impure for other reasons as well). Unstripped binaries: may be contaminated by build-id. Can be avoided either by passing ld --build-id=none param or careful stripping. Needs testing. Luckily this is a very small subset of packages. I looked at man ld and I think we rather want --build-id=sha1 as it's explicitly stated that the ID is uniquely determined by the output. I haven't checked for sure but vandenoever's tests seem to indicate that the default build id is in fact sha1 and it depends on the build dir :( Ah, well, from [buildID docs] it doesn't seems so, but we can do with --build-id=none... paths are unique IDs already :-) [buildID docs] https://fedoraproject.org/wiki/Releases/FeatureBuildId#Add_BuildID_Support Vlada smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
Also, by default we have address space layout randomization, which can be another source of build non-determinism. It has some security advantages, but if we find that it really makes difference, then we can disable it for builds (not for regular running). http://www.win.tue.nl/~aeb/linux/hh/protection.html Vlada smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
В письме от Вторник 25 июня 2013 14:17:35 пользователь Vladimír Čunát написал: Also, by default we have address space layout randomization, which can be another source of build non-determinism. It has some security advantages, but if we find that it really makes difference, then we can disable it for builds (not for regular running). http://www.win.tue.nl/~aeb/linux/hh/protection.html This happens at runtime. Nothing of what is currently enabled causes nondeterminism, or at least I'm yet to find an example. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
On 06/25/2013 02:24 PM, phree...@yandex.ru wrote: Nothing of what is currently enabled causes nondeterminism, or at Great. There's no need to sanitize nondet. sources that aren't used (e.g. there's gethostid). But the time is everywhere... many apps just must know how/where/when they were built (e.g. see uname -v). smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
В письме от Вторник 25 июня 2013 14:28:14 пользователь Vladimír Čunát написал: On 06/25/2013 02:24 PM, phree...@yandex.ru wrote: Nothing of what is currently enabled causes nondeterminism, or at Great. There's no need to sanitize nondet. sources that aren't used (e.g. there's gethostid). But the time is everywhere... many apps just must know how/where/when they were built (e.g. see uname -v). In fact, sanitization is a very useful thing if you want to reliably cache builds. If you intercept all syscalls, you can have a total list of build inputs(not only files). Basically, the build system has no other option but to produce the same output(and thus it can be safely cached), unless it performs a benchmarking attack to get some entropy. The most popular such attack is parallel builds :) It's quite possible that there's a useful combination of letting some syscalls pass(like reading files from nixos store), sanitizing others and patching the build system to not touch weird stuff. Useful for caching most of cpu-intensive stuff that is. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
Many syscalls (uname, gettimeofday, etc.) and OS interfaces (/proc, /dev, /sys, etc.) leak info. Name spaces, personality(2), and similar help, but it looks like an endless quest. Ludo’. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
Hi Evgeny Egorochkin, I've created this page long time ago: https://nixos.org/wiki/Nix_impurities So how do you exactly fix those impurities? Maybe consider updating that wiki adding a line fixed by doing X Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deterministic(bit-perfect) Builds
В письме от Вторник 25 июня 2013 15:40:11 пользователь Marc Weber написал: Hi Evgeny Egorochkin, I've created this page long time ago: https://nixos.org/wiki/Nix_impurities So how do you exactly fix those impurities? Not all these impurities need to be fixed. In fact it's enough to simply terminate the build if it does something really unusual and ask the user to patch it. If the build system really wants to break purity, it can launch a benchmarking attack anyway. But then again such a build system can be quickly found and patched assuming that 99.9% of other packages build reliably. I have hard time coming up with any way to weaponize benchmarking. It can be used to roughly identify the building machine.If the number of users is small, it can compile in a backdoor targetted to a paranoid user who compiles everything from source if this user's hardware config is known and unique. But this requires that the source code is already compromised so all these tricks are probably useless. Maybe consider updating that wiki adding a line fixed by doing X As I said, I'd rather identify the rare build that does most of those nasty things and fix it. I would try intercepting and sanitizing date, uname, /proc/meminfo. let file access to the build dir and nix store flow freely and abort for everything else +- some minor tweaks. Shouldn't be too hard and would cover a very large subset of builds. There might be some nastiness with tests though :( ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
