Live data from Hacker News

Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

discourse.nixos.org

41–50 of 232 posts

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#41
post #39
post #33

Earlier quoted context omitted.

I totally believe it is possible, it is perhaps more of a cultural thing.

It's the pragmatic thing. I wouldn't use nixOS if I wasn't able to use it on a 16 core modern desktop. I don't think there's a performant and 100% FLOSS compatible computer that wouldn't make me want to gouge my eyes out with a rusty spoon when building stuff for ARM.

Talos has 44 core/176 thread server options which can take 2 TBs of DDR4 that are FSF certified. The board firmware is also open and has reproducible builds.

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#42
post #34

Hopefully this will one day also work with NVidia's software packages.

The trick with nvidia on Linux is to not expect that they will ever work on anything. If you want to be sure that stuff works, either don't buy Nvidia or use Windows.

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#43
post #34

Hopefully this will one day also work with NVidia's software packages.

The trick with nvidia on Linux is to not expect that they will ever work on anything. If you want to be sure that stuff works, either don't buy Nvidia or use Windows.

What would you recommend instead of NVidia's Jetson embedded platform?

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#44
I really want to adopt Nix and NixOS for my systems but the cost of wrapping packages is just a little too high for me right now (or perhaps I'm out of date and a new cool tool that does it automatically is out). IMHO, a dependency graph-based build system that builds a hermetically sealed transitive closure of an app's dependencies that can be plopped into a rootfs via Nix [0] is far superior security wise to the traditional practice of writing docker files.

[0] https://yann.hodique.info/blog/using-nix-to-build-docker-ima...

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#45
post #25
post #11

This really deserves more love. Who remembers Ken Thompson's "Reflections on Trusting Trust"? The norm today is auto-updating, pre-built software. This places a ton of trust in the publisher. Even for open-source, well-vetted software, we all collectively cross our fingers and hope that whoever is building these binaries and running the servers that disseminate them, is honest and good at security. So far this has mo…

This is great! The one fly in the ointment, pardon, is that Nix is a bit lax about trusting proprietary and binary-only stuff. It would be great if there were a FLOSS-only core system for NixOS which would be fully transparent.

> It would be great if there were a FLOSS-only core system for NixOS

Might be wrong but isn't this part of the premise for Guix/GuixSD?

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#46
post #31
post #29

Earlier quoted context omitted.

This smaller bootstrap seed thing is a different problem from reproducible builds. nixpkgs does still have a pretty big initial TCB (aka. stage0) compared to Guix. But as far as I can tell NixOS has the upper hand in terms of how much can be built reproducibly (aka. the output hash matches across separate builds).

Bootstrapping from a very small binary core (I think 512 bytes) with an initial C compiler written in Scheme also has the advantage that the system can easily be ported to different hardware. Which is one major strength of the GNU projects and tools.

Not necessarily. Usually these very small cores end up being more architecture specific binaries than a stage0 consisting of gcc + some other core packages. A good illustration of this is that Guix's work on bootstrap seed reduction has been so far mostly applied to i686/amd64 and not even other architectures they support (at least, not fully).

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#47
post #43

Earlier quoted context omitted.

The trick with nvidia on Linux is to not expect that they will ever work on anything. If you want to be sure that stuff works, either don't buy Nvidia or use Windows.

What would you recommend instead of NVidia's Jetson embedded platform?

I'm not familiar with the market the Jetson is in and what purposes it serves. From a quick Google, it seems to build boards for machine learning? If that's true, I'm pretty sure Google and Intel have products in that space, and I'm sure there's other brands I don't know of.

If Nvidia has its own distribution, it might well work for as long as it's willing to maintain the software because then they can tune their open source stuff to make it work with their proprietary drivers, the same way Apple is hiding their tensorflow code. I still would be hesitant to rely on Nvidia in that case given their history.

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#48
post #35

Earlier quoted context omitted.

Who are you going to trace it back to if not the maintainer anyways? If the delivery method then why is the delivery of the source from the maintainer inherently any safer?

Even if the original attack happened upstream, if the upstreamed piece of software was pinned via git, then it'd be trivial to bisect the upstream project to find the culprit.

This is great if you are looking at attributing blame. Not so great if you are trying to prevent all the worlds computers getting owned....

I'd imagine that if I were looking at causing world wide chaos, I'd love nothing better than getting into the tool chain in a way that I could later on utilise on a wide spread basis.

At that point I would have achieved my aims and if that means I've burnt a few people along the way, so be it, I'm a bad guy, the damage has been done, the objective met.

Re: Nixos-unstable’s ISO_minimal.x86_64-Linux is 100% reproducible

#49
post #7
post #2

Can anyone comment on the significance of this accomplishment, and why it was hard to achieve before? I (naively, apparently) assumed this had been possible with open-source toolchains for a long time.

Just recently, there were large non-reproducible projects: python, gcc. Not sure where is the history of non-r13y. --- There is Debian initiative to create bit-to-bit reproducible builds for all their software (well, all critical). https://reproducible-builds.org/ R13y is akin to "computer proofs" in math -- if you don't have it, that's fine, but if you have it, that's awesome. There are practical reasons to favor re…

>- Nix tooling was created 15 years ago exactly for this, Nix is mad to make packages bit-to-bit rebuildable from scratch.

I don't think this is accurate?

Nix is about reproducing system behaviour, largely by capturing the dependency graph and replaying the build. But this doesn't entail bit-for-bit identical binaries. It's very much sits in the same group such as Docker and similar technologies. This is also how I read the original thesis from Eelco[0].

And well, claims like this always rubs me the wrong way since nixos only really started using the word "reproducible builds" after Debian started their efforts in 2015-2016[1], and started their reproducible builds effort later. It also muddies the language since people are now talking about "reproducible builds" in terms of system behavior as well as bit-for-bit identical builds. The result has been that people talk about "verifiable builds" instead.

[0]: https://edolstra.github.io/pubs/phd-thesis.pdf

[1]: https://github.com/NixOS/nixpkgs/issues/9731

Post reply on HN