I’m new to Nix and wanted to get my feet wet by using the Nix package manager. However, I wasn’t sure how these packages were made. Are these packaged by the community? Who do I need to “trust” when installing these packages? In general, I was looking for info on how nix packages are made and maintained.

  • hallettj@beehaw.org
    link
    fedilink
    English
    arrow-up
    10
    ·
    1 year ago

    The packages are defined in a Github repo, https://github.com/NixOS/nixpkgs. That contains the sources for all of the Nix expressions. Usually when you install packages you get pre-built binaries that are produced from the expressions in the repo through an automated system.

    There is a group of “committers” who have the authority to merge PRs (pull requests) to the nixpkgs repo. There is a tracking issue for nominating new committers. That issue also describes criteria that new committers should meet. I found a comment claiming that there are 139 committers - but that comment is a few years old.

    Packages are maintained by a larger group of authors who submit new packages or updates via PRs. Committers review these PRs before they can be merged. A key criteria for becoming a committer is to author a sizable number of PRs that go on to be approved through this process.

    I didn’t see descriptions of any measures that would prevent committers from making whatever changes to nixpkgs they choose to. Also package hashes are not a cryptographically-secure proof of reproducibility - it is technically possible to tamper with binaries in some ways that don’t change hashes. So your trust in nixpkgs is based on,

    • vetting of committers
    • committers being sufficiently diligent in PR reviews
    • security of the build system
    • enough eyes on the project to catch a problem quickly if some malicious change does get through

    As a system it looks good enough to me. People have to demonstrate a commitment to the project, and an ability to do the work to get the keys to the system. Personal reputations are at stake which I think is a solid motivator to act in good faith. I think if a malicious change did get in it would probably be caught quickly.

    • Atemu@lemmy.ml
      link
      fedilink
      English
      arrow-up
      8
      ·
      1 year ago

      found a comment claiming that there are 139 committers - but that comment is a few years old.

      The current size of the Nixpkgs committers team is 197.

      A key criteria for becoming a committer is to author a sizable number of PRs that go on to be approved through this process.

      Not only that but also reviews and other community interactions.

      You must be “known” among existing committers and have shown that you understand the “rules” of Nixpkgs; written and unwritten ones.

      I didn’t see descriptions of any measures that would prevent committers from making whatever changes to nixpkgs they choose to.

      That is correct. We could push any commit we wanted into Nixpkgs.

      Others would (hopefully) notice though and there’s a bot which tells you “nono, bad committer” when you push a commit without PR ;)

      package hashes are not a cryptographically-secure proof of reproducibility - it is technically possible to tamper with binaries in some ways that don’t change hashes

      It’s possible to tamper with the binary but not the source code. A substantial change in build recipe always causes a change in derivation hash. Malicious code must be introduced in source code form.

      To tamper with binaries, you’d need access to Hydra; more specifically its signing key. Committers do not have that kind of access.

      Personal reputations are at stake which I think is a solid motivator to act in good faith. I think if a malicious change did get in it would probably be caught quickly.

      Well, that’s the hope anyways. Thankfully, we haven’t had this system abused yet but I’d be more comfortable if there was a better system in place. Especially w.r.t. removing inactive committers that haven’t actually been part of the project for a long time.

    • hallettj@beehaw.org
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      I realized that I didn’t answer the basic question, what person or organization is behind all this? That would be the NixOS Foundation. You can get some information on the people involved in the “Teams” section on this page, https://nixos.org/community/

  • 𝕙𝕖𝕝𝕡@lemmy.ml
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    Trust is a broad term. If you’re paranoid, find the package you care about here, and read every line:

    https://github.com/NixOS/nixpkgs

    If you’re slightly less paranoid, check the git blame logs for anyone that’s touched a package you care about. If you trust all of them, then you’re good.

    If you’re less paranoid than that, assume that someone reasonable is in charge of that repo. You’ll get warnings about insecure packages. I’ve had to Ok a few insecure packages in my configuration.nix, because I assume the packagers are reasonable people. I may yet find out I’ve made a mistake.

    Broadly speaking, I think it’s the same model as any other distro. Debian for example has volunteers that package stuff. You can go through the same process above and decide how paranoid you want to be for that as well.

      • Atemu@lemmy.ml
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        Manually.

        There have been efforts to automate this partially but they’ve stalled.

      • 𝕙𝕖𝕝𝕡@lemmy.ml
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        I’ll be honest, I have no idea. Sometimes, I get nagged that a package is insecure, and it seems reasonable like an old version of Electron, and then I just sigh and add it to my list of packages to ignore that warning on.

        • agile_squirrel@lemmy.mlOP
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          I didn’t find anything concrete, but it seems that a package is automatically marked insecure if it has a dependency that has a known CVE. I wonder how that is done.