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.
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.
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”
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.
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