My wishlist for NixOS security in 2024+

[Atemu]

@don.dfh

Is my system affected by known vulnerabilities.

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

@Atemu

The latter category should just be fixed through an update because it’s an equal amount of effort.

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.

[Atemu]

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.

[nixinator]

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

i find Ubuntu kinda space age.

[RaitoBezarius]

@Atemu

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.

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.

[RaitoBezarius]

@don.dfh

This sounds like a very bad idea as it makes it impossible to answer the simple question: Is my system affected by known vulnerabilities.

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 .

[don.dfh]

@Atemu

If we needed to update Nixpkgs to let you know you have a vuln, we might aswell just fix the vuln via an update.

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

@Atemu

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.

@RaitoBezarius

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

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

@nixinator

hows it that team funded?

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

@nixinator

i find Ubuntu kinda space age.

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

[Atemu]

@RaitoBezarius

Our builder for Rust for example are technically fromSourceVendored, right?

Enabling that policy check would reduce the set of usable packages to a meager

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

@RaitoBezarius

I think we should also aim to track the vendoring information, while having this metadata.

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”

[RaitoBezarius]

@Atemu

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

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.

@Atemu

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

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.

@Atemu

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”

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.

[delroth]

@RaitoBezarius

We simply don’t have the right tooling to unvendor everything at the derivation level

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.

[RaitoBezarius]

@delroth

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.

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.

[delroth]

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

(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.)

[pbsds]

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

[nixinator]

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

[pbsds]

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