Is there a better `problems` "maintainerless" for system auditing?

Help
1

relevant docs link: https://nixos.org/manual/nixpkgs/stable/#sec-problems

I wanted to audit my own system for packages which don’t have maintainers and found the above docs showing that there is a “maintainerless” kind of problem and how to instantiate <nixpkgs> to warn when a package has that problem. Looked promising.

I decided to test in a repl like so:

nix repl
Nix 2.34.8
Type :? for help.
nix-repl> pkgs = import <nixpkgs> { config.problems.matchers = [ { kind = "maintainerless"; handler = "warn"; } ]; }

And then when I evaluate pkgs.xz I see a bunch of “maintainerless” packages.

nix-repl> pkgs.xz
evaluation warning: Package 'bison-3.8.2' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/bi/bison/package.nix:55 has the following problem: maintainerless: This package has no declared maintainer, i.e.
an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'gnum4-1.4.21' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/gn/gnum4/package.nix:51 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'expand-response-params' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/ex/expand-response-params/package.nix:30 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'expand-response-params' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/ex/expand-response-params/package.nix:30 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'gmp-6.3.0' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/development/libraries/gmp/6.x.nix:83 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'mpfr-4.2.2' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/mp/mpfr/package.nix:76 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'libmpc-1.4.1' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/li/libmpc/package.nix:39 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'isl-0.20' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/development/libraries/isl/generic.nix:50 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'patchelf-0.15.2' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/development/tools/misc/patchelf/default.nix:33 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'autoconf-2.69' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/development/tools/misc/autoconf/2.69.nix:46 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'libunistring-1.4.2' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/development/libraries/libunistring/default.nix:68 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'xz-5.8.3' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/tools/compression/xz/default.nix:82 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'patchelf-0.15.2' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/development/tools/misc/patchelf/default.nix:33 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'xz-5.8.3' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/tools/compression/xz/default.nix:82 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'binutils-patchelfed-ld-wrapper-2.46' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/build-support/bintools-wrapper/default.nix:487 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'expand-response-params' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/ex/expand-response-params/package.nix:30 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'gmp-6.3.0' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/development/libraries/gmp/6.x.nix:83 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'mpfr-4.2.2' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/mp/mpfr/package.nix:76 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'libmpc-1.4.1' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/li/libmpc/package.nix:39 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'isl-0.20' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/development/libraries/isl/generic.nix:50 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
evaluation warning: Package 'expand-response-params' in /nix/store/1idms180igdck24bs1327f8l5pd6r2mz-source/pkgs/by-name/ex/expand-response-params/package.nix:30 has the following problem: maintainerless: This package has no declared maintainer, i.e. an empty `meta.maintainers` and `meta.teams` attribute. See https://nixos.org/manual/nixpkgs/unstable#sec-problems
«derivation /nix/store/869a4capm7n9g9k0kyy2v1r2h6g73y1y-xz-5.8.3.drv»

nix-repl>

As you can see, there are a lot of pretty standard packages with the “maintainerless” label. This label appears to be trivially correct, in that the files declaring these packages often don’t set a meta.maintainers or meta.team. However, it also is pretty trivially useless as a label if even these packages are getting flagged as having this problem, and I don’t really believe that these packages are unmaintained in a practical sense. I tried evaluating my own NixOS system config against this option and there is so much noise that it’s hard to do an eyeball audit.

Is there a better method to audit my system?

1 Like
2

I mean it’s true, these packages aren’t maintained… e.g. bison hasn’t had upstream updates in 5 years so maybe that’s acceptable, but yeah, the last actual maintenance on this package was in Dec 2025. It’s only going to get drive-by maintenance, which we don’t really have a way to guarantee will continue to happen.

1 Like
3

Does nixpkgs have the concept of core / protected pkgs?

While it’d be good for these pkgs to have maintainers, it’s kinda concerning that anyone could maintain e.g. xz.

4

Not exactly, although more recently a security team has been created, which is designed to give best-effort security reviews on changes to critical packages.

This probably wouldn’t be as bad as you’re imagining. Unlike something like the AUR, every non-automated change in Nixpkgs needs to be approved by one of ~200 trusted committers, so just being a maintainer doesn’t provide much ability to inject something nefarious.

1 Like
5

I agree that the situation here is better. I personally would feel better if critical/core pkgs were required to be signed off by multiple committers. Though I guess a security team could handle that as well.

6

I wouldn’t read too much into xz not having a listed maintainer, and I would expect that any PR which is more than updating the version number + hash would be scrutinized carefully.

1 Like
7

GNU bison is a 41 year old piece of software; I’m not as concerned if it’s update cadence is slow. And although I understand that upstream also needs to be part of any security stance, when investigating nixpkgs.*.meta, I’m more interested in their maintenance status vis-a-vis nixpkgs specifically. One thing at a time, etc.

The end goal that I was trying to reach by tapping into the “maintainerless” problem in nixpkgs was to have better insight into which packages might not get eyes if/when an update occurs. Maybe I’m wrong, but considering that bison gets evaluated as part of pkgs.stdenv I’m reasonably certain that someone will look at it even if it’s kinda drive-by. Maybe I’m wrong/naive but it’s ok enough in my threat model reasoning.

Right now, I think my imperfect solution if I go forward with enabling this warning would be to also whitelist specific packages with problems.handlers.${pkgname}.maintainerless = "ignore";, starting probably with packages within the minimal install. That’s an okish solution to seeing things in my config that are more likely to suffer from maintenance rot without being overwhelmed with other packages that don’t have explicit maintainers but that I judge as likely to plod along ok even without such dedicated maintainers. I probably won’t even do anything with “maintainerless” packages in my system config, but it’s better to be eyes-wide-open about this sort of thing.

I still wonder whether there’s a better approach that other people take. The post has only been up for <24 hours though, so I’ll give it time and maybe someone will. I’m no worse off if no one answers, whereas I might discover something new if someone does.

8

Naive is probably not the right word, but I think your threat model demands a different solution. The metadata you have available isn’t useful for your threat assessment.

The inverse problem also happens; There are many packages with listed maintainers who have been unresponsive for years. And I’d argue that drive-by contribution only really isn’t ideal for such critical packages; even if they are low-effort, having someone responsible for them is still a big deal. The bystander effect is real.

Nobody is really maintaining the maintainers metadata, we don’t have organizational processes in place to do so. This metadata is just short of useless to assess whether packages are actually “maintained”.

It also doesn’t say much about maintenance quality; NixOS will definitely not be the distro that detects the next xz-style supply chain attack.

If your ultimate goal is to spot places where your time would be best spent, stepping up and giving these “core” expressions a facelift every once in a while would still be useful, and as such the maintainers metadata you’re getting gives you a good heuristic for that.

I wouldn’t use it to figure out whether your supply chain is secure, though. I think nixpkgs is simply not the right package repo for this threat model.

3 Likes
9

I’m reasonably certain that the majority of contributors will avoid touching it because it’s in stdenv and they don’t want to get burned by it.

3 Likes
10

Agreed about the metadata, hence why I was asking if there was a better way to get at it.

It does sound like the conversation is branching down the path of “It didn’t hurt to ask” regarding finding a better way, but at least I’m getting a bit of the “asking let me learn something” branch. Thanks for the additional context!

11

Unless your contention is that every single contributor will avoid touching a stdenv-related package, it seems just slightly off-aim to me in a subtle but important way. If we are talking in hypotheticals, a similar statement is trivially true about almost every package. Considering any single package in nixpkgs, the majority of contributors will avoid touching it (because they aren’t interested in it), yet it does not follow that there is not a single maintained package in nixpkgs.

If there are 200 committers and 199 avoid it but there is 1 active committer who always notices when ryantm suggests an update to stdenv-related packages and prioritizes reviewing+committing them, then there is still timely maintenance. To be fair, I can’t know whether reality roughly concords with this idea, I am just hoping at this point.

12

As someone who’s been around for 3 years at this point, this is a problem unique to stdenv. Most packages get ignored because people don’t care about them, but stdenv has very few people willing to learn about it (and nixpkgs has lost a fair number of contributors who know it well over the years, due to effectively project mismanagement). I do appreciate the people who are willing to step up, but it’s unsustainable IMO.

13

That does sound worrying, and it’s helpful to hear the impression garnered by someone who has been around longer than I. If you truly believe that current maintenance for stdenv is unsustainable, what keeps you on NixOS when basically every package depends on stdenv (since most are written using stdenv.mkDerivation)?

Do you feel that stdenv maintainence status shouldn’t be a big concern for most NixOS users, or what is the hope that makes you believe the situation will change?

Looking into it, there also is Stdenv Team | Nix & NixOS which hopefully is sustainable. If not, what do you think they would need for their efforts to be sustainable?

1 Like
14

I definitely missed that, maybe the stdenv packages could be tagged with that team to make it obvious that they are being taken care of?

15

Strictly speaking I fork nixpkgs and use that instead, rebasing often. I would be more disgruntled if forking wasn’t an option, but it’s open-source after all :slight_smile: It’s reassuring to know there’s a proper stdenv team as of teams: create the stdenv team by RossComputerGuy · Pull Request #347959 · NixOS/nixpkgs · GitHub, but I do personally have my compilation gripes that I’d like to improve in any case. I don’t have an answer for other users, since I suspect we have differing goals.

For NixOS itself, I also do plan to migrate off of the baseline kernel, initrd, etc. so my dependence will go down over time.

1 Like
16

Yeah now that I’ve done the research into this meta.problem and see that there is a team, I’ll probably make a PR to add them to meta.teams attribute sometime soon. An entry for the team already exists in nixpkgs/maintainers/team-list.nix at 09fe5f351396dd7db5024907681b203ada99e800 · NixOS/nixpkgs · GitHub, so I think it’s mostly going through

nix-store --query --references $(nix-instantiate --raw --eval --expr "(import <nixpkgs> {}).stdenv.drvPath") | sed 's/^.\{44,44\}//' | sort | uniq

which returns 103 package names on my system. I could also try to tag all the --requisites, but that’s 912 packages, and I’m not even sure if the stdenv team wants to be tagged. I should probably actually ping them in matrix or something and see if they are open to this before working on the actual PR

1 Like
17

I started work on making maintainerless problems more useful by limiting them to leaf packages and enabling them by default:

Furthermore, there is the security review team (lib.teams.security-review), which is reviewing changes to core packages:

5 Likes