Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

discourse.nixos.org

Post reply on HN
Print view View original

141–150 of 179 posts

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#141

Post by lrvick »

KingMachiavelli wrote: post #139
lrvick wrote: post #138

Earlier quoted context omitted.

"Expecting to use their signatures for anything meaningful strikes me as a bit like expecting product support from a delivery driver." And yet most of the packages from most major linux distributions are signed. If you are going to spend hours maintaining a package, it takes only an extra half a second to tap a yubikey to prevent someone from impersonating you. Package maintainers from say Arch and Debian go through…

Nix doesn't have maintainers sign anything because it isn't necessary. The Nix binary cache is built and signed but that's done by builders only the NiXOS foundation controls. Individual maintainers just commit Nix code to build the packages... Do you mean you want their Git commits to be signed? Edit: I guess that is what you mean. That is distinct from package (binary) signing. How do you know that a distro's repos…

Two people being able to build the same source and get the same result, does not mean the source that was built was the same source the developer originally contributed. Signing git commits would be a great start, easier than what other distros do to solve the same problem. With reproducible builds in place, the biggest remaining risk is someone tampering with git history.

Also packages being built by a central party is actually a problem. What stops someone with ssh access to the build systems from tampering with the results?

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#142

Post by BreakfastB0b »

lrvick wrote: post #141
KingMachiavelli wrote: post #139

Earlier quoted context omitted.

Nix doesn't have maintainers sign anything because it isn't necessary. The Nix binary cache is built and signed but that's done by builders only the NiXOS foundation controls. Individual maintainers just commit Nix code to build the packages... Do you mean you want their Git commits to be signed? Edit: I guess that is what you mean. That is distinct from package (binary) signing. How do you know that a distro's repos…

Two people being able to build the same source and get the same result, does not mean the source that was built was the same source the developer originally contributed. Signing git commits would be a great start, easier than what other distros do to solve the same problem. With reproducible builds in place, the biggest remaining risk is someone tampering with git history. Also packages being built by a central party…

Nix has two types of derivations (builds). Input addressed, and content addressed.

An input addressed derivation’s hash is based on the the hash of all its input derivations and its own derivation. Therefore trusting the association between the cached binary and the derivation requires trusting the builder and a signature. All non-derivation inputs like source code, must be content-addressed.

A content addressed derivation can then be produced easily by rewriting all the derivations with `nix make-content-addressed`. This doesn’t require trust / signatures as every stage of the build is now content-addressed. The final hash could be confirmed through social consensus of multiple distrusting parties.

There’s nothing in theory stopping you from starting with a content addressed derivation other than it being a pain in the ass as you’d have to know the output hash before you built it, or TOFU (trust on first use) it which is then just the same as using the `nix make-content-addressed` approach.

I’m not sure why you think commit signatures are required. Git is content addressed, you can’t tamper with the derivations without changing the hashes and nixpkgs is primarily developed through GitHub. If someone has access to your SSH keys or GitHub account password it stands to reason they’d have access to your GPG keys too.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#143

Post by Ericson2314 »

BreakfastB0b wrote: post #142
lrvick wrote: post #141

Earlier quoted context omitted.

Two people being able to build the same source and get the same result, does not mean the source that was built was the same source the developer originally contributed. Signing git commits would be a great start, easier than what other distros do to solve the same problem. With reproducible builds in place, the biggest remaining risk is someone tampering with git history. Also packages being built by a central party…

Nix has two types of derivations (builds). Input addressed, and content addressed. An input addressed derivation’s hash is based on the the hash of all its input derivations and its own derivation. Therefore trusting the association between the cached binary and the derivation requires trusting the builder and a signature. All non-derivation inputs like source code, must be content-addressed. A content addressed deri…

There are content-addressed derivations that don't require specifying the hash up front either.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#144

Post by lrvick »

BreakfastB0b wrote: post #142
lrvick wrote: post #141

Earlier quoted context omitted.

Two people being able to build the same source and get the same result, does not mean the source that was built was the same source the developer originally contributed. Signing git commits would be a great start, easier than what other distros do to solve the same problem. With reproducible builds in place, the biggest remaining risk is someone tampering with git history. Also packages being built by a central party…

Nix has two types of derivations (builds). Input addressed, and content addressed. An input addressed derivation’s hash is based on the the hash of all its input derivations and its own derivation. Therefore trusting the association between the cached binary and the derivation requires trusting the builder and a signature. All non-derivation inputs like source code, must be content-addressed. A content addressed deri…

I totally grant that the nix system is good at making sure that a given git commit produces a given result. They do a fantastic job at everything from miles 2-10. They just skip the first mile of integrity, which is also one of the easiest to tamper with.

9/10 popular package developers I audit have SMS as a backup account recovery method on their email accounts. Easy to see when I try to reset their email passwords and it says "sms sent to ....". One sim swap and I have the account of a popular package maintainer.

Or, even easier, developers often use custom email domains. Right now there are -thousands- of custom email domains used by package maintainers in NPM for instance, that are expired. Buy domain, and you buy access to contribute commits to an unpopular unnoticed package that a popular package depends on.

Supply chain attacks are my core area of research, and they are easy to do. They are hard to defend against unless you have reproducible builds already. It is crazy NixOS has done so much good work for supply chain integrity and refuses to do the first mile almost every other popular linux distro already makes at least some attempt at.

As for PGP key theft, most people that use PGP today keep the keys on personal HSMs, like a yubikey or nitrokey, such that the private key never comes in contact with the memory of an internet connected computer. Stealing one in most cases would require keylogging the pin, and physically stealing the key.

If you got malware on someones machine, you could still manipulate them at that point in time, though this still will require timing your attack so that they are online and tricking them to tap their key, which dramatically increases attack complexity.

Next level once people sign commits though, is signing code reviews. Then you have removed all single points of failure from your software supply chain.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#145

Post by amarshall »

lrvick wrote: post #133

Now if only they would have maintainers sign packages like almost every other linux distribution has done since the 90s, so we have any idea if the code everyone is building is the same code submitted and reviewed by known individuals. Until signing is standardized, it is hard to imagine using nix in any production use case that protects anything of value.

What distros do this? As far as I can tell Debian doesn’t anymore (the build system signs builds), Fedora doesn’t, and Arch…I can’t tell but I don’t think it does. But maybe I’m wrong.

The NixOS build system signs all build outputs with its key and the signature is verified upon download. If you’re paranoid, Nix at least makes it easy to just build everything from source.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#146

Post by __MatrixMan__ »

lrvick wrote: post #138
__MatrixMan__ wrote: post #137

Earlier quoted context omitted.

My impression of nix package maintainers is that they are providing a useful interface so that software can be composed easily. Most of them are not making any kind of assertion about the contents of the package. Expecting to use their signatures for anything meaningful strikes me as a bit like expecting product support from a delivery driver. You don't need to trust it wasn't packaged maliciously, nix does reproduci…

"Expecting to use their signatures for anything meaningful strikes me as a bit like expecting product support from a delivery driver." And yet most of the packages from most major linux distributions are signed. If you are going to spend hours maintaining a package, it takes only an extra half a second to tap a yubikey to prevent someone from impersonating you. Package maintainers from say Arch and Debian go through…

> The developers github account was compromised due to a sim swap on their email account while they were on vacation, and someone pushed a fake commit as that person.

...which is why it's irresponsible to sign packages unless you have a strong enough relationship with the developer (or are that developer) such that you would notice the malicious release. Signing packages without that level of trust creates a false sense of security in the user.

The Nix approach is to solve the packaging problems in a transparent and verifiable way so that the users can more quickly move from scrutinizing the package to scrutinizing the underlying software--which is where the scrutiny is most helpful anyway.

> we should question the motivations of anyone not willing to do something so basic to protect users.

There are a lot of valid criticisms you could reach for about Nix or its community, but lazy about security just isn't one of them. Our strategy involves different trade-offs than is typical, but that doesn't make them negligent or malicious.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#147

Post by zbentley »

bloak wrote: post #104
Smaug123 wrote: post #83

Earlier quoted context omitted.

Yeah, "who built this" information belongs in a signing certificate that accompanies the build artefact, not in the artefact itself. The Git hash can certainly appear in the binary (it's a reproducible part of the build input), and the date can instead be e.g. the commit date, which is probably more relevant to a user anyway.

Much as I like Git, I'm not sure I like the idea of the artefacts depending on the git commit and therefore on the entire git history. I rather feel the artefacts should only depend on the actual source and not on a particular version control system used for storing the source.

You're welcome to include full sources, or not-tied-to-git directions to acquire them, with your release binaries.

Regardless, whether or not you do that is a discussion of distribution format, not binary reproducibility. Your distribution can contain as much (or as little) additional material as you like along with your release binaries.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#148

Post by __MatrixMan__ »

lrvick wrote: post #144
BreakfastB0b wrote: post #142

Earlier quoted context omitted.

Nix has two types of derivations (builds). Input addressed, and content addressed. An input addressed derivation’s hash is based on the the hash of all its input derivations and its own derivation. Therefore trusting the association between the cached binary and the derivation requires trusting the builder and a signature. All non-derivation inputs like source code, must be content-addressed. A content addressed deri…

I totally grant that the nix system is good at making sure that a given git commit produces a given result. They do a fantastic job at everything from miles 2-10. They just skip the first mile of integrity, which is also one of the easiest to tamper with. 9/10 popular package developers I audit have SMS as a backup account recovery method on their email accounts. Easy to see when I try to reset their email passwords…

You're talking sense, but this is due diligence for a developer, not for an operating system or a package manager.

You're free to map your package definitions to the commits they contain and verify any signatures that you find there, but that process will have nothing to do with whether other people have signed the instructions that your machine follows to fetch and build the contents of that commit.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#149

Post by __MatrixMan__ »

amarshall wrote: post #10
rgoulter wrote: post #5

Earlier quoted context omitted.

Yeah, Nix is a tough tool to learn. It's probably never the right tool to pick for "I just want something that works right now" if you're unfamiliar with it. > I thought one of the main reason for nixos's existence is reproducibilty NixOS uses "reproducible" to mean "with the same Nix code, you get the same program behaviour". This is more/less what people hope Dockerfiles provide. This is the level of reproducibilit…

> NixOS uses "reproducible" to mean "with the same Nix code, you get the same program behaviour". Note that ”Nix code” also includes the hashes of all non-Nix sources. One way to think of it is that Nix has reliable build cache invalidation. > This is more/less what people hope Dockerfiles provide. Indeed, but importantly they do not provide input-reproducibility (while Nix does) because, at least, there are no hashe…

PSA: you can build OCI images with nix, then they'll be a pure function of their input like we've all wished was the case with Dockerfiles.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#150

Post by __MatrixMan__ »

flkiwi wrote: post #51
Aerbil313 wrote: post #31

Earlier quoted context omitted.

Check out https://github.com/donovanglover/nix-config . Flake based config with hyprland and cool stuff. > at that point I gave up. NixOS is not for the weak or time constrained, currently. Hopefully it will be one day. Still if you push through, you reap the benefits.

Another good option: https://github.com/Misterio77/nix-starter-configs I started with this one, the minimal version, then moved on to something more like the standard version, and now I'm moving on to something based on his much more complicated and flexible build in a different repo. I had been flailing, then this repo made it click.

Same here, that repo is fantastic.
Post reply on HN