My wishlist for NixOS security in 2024+

I too think this is an important need but knownVulnerabilities is simply not the way to do that IMHO.

If we needed to update Nixpkgs to let you know you have a vuln, we might aswell just fix the vuln via an update. That’s what I meant by

To actually answer that question, we must either have the ability to inspect a system closure to find vulnerable software (most direct approach) or be able to inspect a Nixpkgs revision with updated external vuln info.

I can see arguments for either and I’m not sure which would be more practical.


RE: Vendoring

What would you think of a fromSourceVendored source type for from-source packages which vendor library code that we have packages for?

Just like binaryNativeCode, packages should strive towards regular fromSource by patching the source, providing paths via configure flags or whatever means there are to avoid vendored libraries wherever possible.

I do not believe efforts like this are feasible for us to do for every major CVE in often-vendored core libraries. Therefore, I’d also propose a policy to not care about security issues in such packages as, by the process of vendoring, keeping the deps up-to-date is upstream’s responsibility, not ours.
Users who do not trust upstream developers to do that could then disallow hasVendoredDeps = true just like isSource = false can be disallowed.


hows it that team funded? I’m just curious about how these linux projects hangs together… .

i find Ubuntu kinda space age.

While I agree, I think it’s interesting if we are also able to restore the lack of information caused by those issues. Our builder for Rust for example are technically fromSourceVendored, right?

Enabling that policy check would reduce the set of usable packages to a meager, so I think we should also aim to track the vendoring information, while having this metadata.


Knowing if your system is affected by vulnerability cannot only be done at evaluation time, it must be continuously done.

We need better tools for that and we will see if we will have such in the next months :slight_smile:.


I fully agree - thanks to your clarification I realized my assumption was that the vuln feed would be outside of nixpkgs to begin with.

I can think of use-cases for both mechanisms within my environments.

I don’t know, but their GettingInvolved doc leaves me with an impression of community driven (+ sharing workload w/ Debian) and some paid folks over at Canonical

Yeah don’t get me started on the pain of running an audited CA on that space-ship :see_no_evil:

1 Like

It would indeed. The fact that (nearly?) all rust packages vendor deps is …not great IMHO.

Perhaps a fromSourceVendored marking could provide some incentive to replace these source vendor tarball setups with proper language package sets (i.e. haskell).

I too think this would be useful but, as I said, I don’t think it’s feasible for us to care about vendored source deps to a great degree.
I’d rather see this as a tool for users to go bug upstreams directly about it and then get those updates pushed through with perhaps a little more “pressure” :wink:

This kinda goes the same for Go, for Node.js, for many things. We simply don’t have the right tooling to unvendor everything at the derivation level, we can only afford to know about what is vendored and maybe build tooling to perform vendor-patching on the fly. But all of that seems messy IMHO.

I don’t believe so, if everyone does like Haskell, a lot of folks will ragequit because this will make the repo explode in terms of size. Something has to be invented here.

Right, but as you can see above, I don’t see a reasonable future where we unvendor such things, whereas we will have to deal with an influx of Rust packages, etc. Which one should commit the lockfile, which one should not, etc.

At least, we should be able to push the information to the door and look if it’s easier to unvendor vs. patching vendored dependencies uniformly.

It’s not just a tooling problem, it’s also that software developed in these ecosystem often lock all dependencies to specific versions, and compatibility across versions is hard to evaluate.

What we could have is a way of detecting leaf packages in these vendored ecosystems that have known vulnerable dependencies for a given amount of time (e.g. 2 weeks) without a new upstream release, and automatically sending a PR marking the leaf packages vulnerable themselves at this point if upstream hasn’t fixed their vulnerability issue.


Though, we could aggressively say that inclusion in nixpkgs require living in a reasonable ecosystem of dependencies à la Stackage. I don’t know how much package would we have to remove if we enforced this rule, like Python does.

Well, we can look at how things went with node2nix to get an idea, I guess :slight_smile:

(I don’t think Rust/Go/NPM/Java are significantly different from each other wrt. dependency management, so I suspect lessons from one can be roughly applied to the others.)

1 Like

I’ve mentioned this idea before in an issue, but a step in the right direction could be to copy lockfiles or some other listing of the vendored deps to a sbom output. This would make it far easier to fetch from the cache and analyse


is that something you could work on? this sounds interesting, to make a proof of value / proof of concept?

I can put it in my backlog, but it is sizeable