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
    2
    ·
    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.

    • hallettj@beehaw.org
      link
      fedilink
      English
      arrow-up
      1
      ·
      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/

    • Atemu@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      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.