4 ms·

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 everyon

by lrvick 3y ago

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.

__MatrixMan__ 3y ago
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 reproducible builds so you can just look at the derivation and build it yourself if you don't feel like relying on the binary cache. As for whether the underlying contents are malicious, that's between you and the developer. If other distributions have have lead you to believe otherwise, then I think they have misled you. The only exception I can think of is Tails, and they don't exactly have the breadth that Nix does.
- lrvick 3y ago
  "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 a vetting process, multiple people sign their keys, and it is a responsibility. Yes, it is volunteer, but there are also volunteer firefighers. Some volunteer jobs are important to keep others safe, and they should be done with care. If Arch, Debian, Fedora, Ubuntu can all sign packages, then this excuse does not really hold for Nix. "You don't need to trust it wasn't packaged maliciously, nix does reproducible builds so you can just look at the derivation and build it yourself if you don't feel like relying on the binary cache." Reproducible builds and package definition signing solve totally different problems. Assume you trust a given developer has been maintaining a package non-maliciously, then you see they made a new update, and so you and other people trust it and build it. You get the same result, so you trust the binaries too. However, you still end up with malware. How? Simple. 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. Or maybe a malicious Github employee is bribed to serve manipulated git history only to the reproducible build servers but to no one else, so it goes undetected for years. Supply chain attacks like this are becoming very common, and there is a lot of motivation to do it to Linux distributions which power systems worth billions of dollars regularly. It is also so easy to close these risks. Just tap the damn yubikey or nitrokey when it blinks. It is wildly irresponsible not to mandate this, and we should question the motivations of anyone not willing to do something so basic to protect users.
  - KingMachiavelli 3y ago
    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 built using the signed commits? NixOS is actually better suited to prove that an particular commit produced the package.
    - lrvick 3y ago
      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?
      - BreakfastB0b 3y ago
        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.
amarshall 3y ago
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.
- lrvick 3y ago
  Yes packages are reproduced and signed. I get that and this is fantastic. That is not the big gap I am talking about which is making sure the expressions themselves even use the correct sources and are not tampered with. Making sure the central signing key is not compromised is pretty critical too, but that can be mitigated with independent reproduction servers that also sign, requiring a minimum of 3 before a new package is trusted. As for Debian, maintainers must still all be part of the web of trust with an application process and a registered key in the web of trust to contribute packages. https://wiki.debian.org/DebianMaintainer#step_5_:_Keyring_update https://wiki.debian.org/DebianMaintainer#step_5_:_Keyring_up... Arch also still has each maintainer sign the packages they maintain, and there is a similar approval process to earn enough trust in your keys to become a maintainer, so there is a decentralized web of trust. Then you add reproducible builds on top of that to almost complete the story. Signed reviews would remove the remaining SPOFs in debian and arch but sadly no one does this. Nix however does not even allow -optional- key pinning or verify signatures of any authors that choose to sign expressions or their commits, so NixOS is way behind Arch and Debian in this respect.
  - amarshall 3y ago
    Ah so you’re talking about the package sources (e.g. Nix files, PKGBUILD, etc.). I guess that’s closer to commit signing, I think? Well Nixpkgs maintainership is much more bazaar than cathedral, for better or worse, and that stymies some of that. However most Nixpkgs maintainers do not have commit access at all. Nixpkgs is at least moving the right direction (I think) by limiting the power of committers to submit changes without review. Should Nixpkgs committers sign their commits? Probably, yea.

by lrvick 3y ago

__MatrixMan__ 3y ago

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 reproducible builds so you can just look at the derivation and build it yourself if you don't feel like relying on the binary cache. As for whether the underlying contents are malicious, that's between you and the developer. If other distributions have have lead you to believe otherwise, then I think they have misled you. The only exception I can think of is Tails, and they don't exactly have the breadth that Nix does.

lrvick 3y ago
"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 a vetting process, multiple people sign their keys, and it is a responsibility. Yes, it is volunteer, but there are also volunteer firefighers. Some volunteer jobs are important to keep others safe, and they should be done with care. If Arch, Debian, Fedora, Ubuntu can all sign packages, then this excuse does not really hold for Nix. "You don't need to trust it wasn't packaged maliciously, nix does reproducible builds so you can just look at the derivation and build it yourself if you don't feel like relying on the binary cache." Reproducible builds and package definition signing solve totally different problems. Assume you trust a given developer has been maintaining a package non-maliciously, then you see they made a new update, and so you and other people trust it and build it. You get the same result, so you trust the binaries too. However, you still end up with malware. How? Simple. 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. Or maybe a malicious Github employee is bribed to serve manipulated git history only to the reproducible build servers but to no one else, so it goes undetected for years. Supply chain attacks like this are becoming very common, and there is a lot of motivation to do it to Linux distributions which power systems worth billions of dollars regularly. It is also so easy to close these risks. Just tap the damn yubikey or nitrokey when it blinks. It is wildly irresponsible not to mandate this, and we should question the motivations of anyone not willing to do something so basic to protect users.
- KingMachiavelli 3y ago
  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 built using the signed commits? NixOS is actually better suited to prove that an particular commit produced the package.
  - lrvick 3y ago
    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?
    - BreakfastB0b 3y ago
      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.

amarshall 3y ago

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.

lrvick 3y ago
Yes packages are reproduced and signed. I get that and this is fantastic. That is not the big gap I am talking about which is making sure the expressions themselves even use the correct sources and are not tampered with. Making sure the central signing key is not compromised is pretty critical too, but that can be mitigated with independent reproduction servers that also sign, requiring a minimum of 3 before a new package is trusted. As for Debian, maintainers must still all be part of the web of trust with an application process and a registered key in the web of trust to contribute packages. https://wiki.debian.org/DebianMaintainer#step_5_:_Keyring_update https://wiki.debian.org/DebianMaintainer#step_5_:_Keyring_up... Arch also still has each maintainer sign the packages they maintain, and there is a similar approval process to earn enough trust in your keys to become a maintainer, so there is a decentralized web of trust. Then you add reproducible builds on top of that to almost complete the story. Signed reviews would remove the remaining SPOFs in debian and arch but sadly no one does this. Nix however does not even allow -optional- key pinning or verify signatures of any authors that choose to sign expressions or their commits, so NixOS is way behind Arch and Debian in this respect.
- amarshall 3y ago
  Ah so you’re talking about the package sources (e.g. Nix files, PKGBUILD, etc.). I guess that’s closer to commit signing, I think? Well Nixpkgs maintainership is much more bazaar than cathedral, for better or worse, and that stymies some of that. However most Nixpkgs maintainers do not have commit access at all. Nixpkgs is at least moving the right direction (I think) by limiting the power of committers to submit changes without review. Should Nixpkgs committers sign their commits? Probably, yea.