Policy/Procedure for additions to knownVulnerabilities with dependents

[fabianhjr]

Starting the conversation on how to handle the additions of knownVulnerabilities.

I am more inclined on merging as soon as possible to notify affected downstream users when doing so doesn't cause mass breakages but there is no policy/procedure in place specially around how to notify maintainers.

This issue was raised as a comment on marking qt5.webengine having known vulnerabilities: #435067 (comment)

cc @NixOS/security

[azahi]

Merging ASAP is reasonable depending on severity, this I believe should be discussed further with the security team. I think package maintainers should be notified if the vulnerable package is a hard dependency, either before approving/merging or after as soon as possible. Making a tracking issue with checkboxes and pings would be great for example.

[SuperSandro2000]

This would be a no brainer if the package would still be build by hydra as otherwise for bigger builds we essentially force people out of the package as they sometimes cannot build the package on their hardware in a reasonable amount of time.

[emilazy]

Notifying maintainers is a good idea and we should definitely do it. Whether to block on a response depends on the scale of the impact and the severity of the issue. In this case, it’s a browser engine that had been EOL with no updates in four months; that’s pretty severe, and compared to how we’ve handled other browsers that go EOL or fall behind on updates, the marking was months overdue, so we would not have wanted to delay longer than it took to get the easy majority of the unnecessary dependencies dealt with.

@SuperSandro2000 Let’s please not relitigate the clear outcome of #351429 every time anything to do with knownVulnerabilities comes up. It after all has nothing to do with notifying package maintainers when a security warning is about to be added to their closures. In fact, the case that caused a maintainer to raise this issue, libsForQt5.qtwebengine, is still cached on nixos-unstable right now.

[chrisheib]

This also was a concern with #360897 libsoup.

[LeSuisse]

I also agree that a notification of some sort, notably for downstream consumers, would be nice but I see this is discussed in the sub-issue.

I see the knownVulnerabilities tag as a way to tell nixpkgs consumers that we (nixpkgs maintainers) are aware of an issue, have triaged it, but cannot address it in the short or medium term. As a consumer, you now have to evaluate whether the issue is relevant to your use cases/threat model, but ultimately you are on your own.

In my opinion the knownVulnerabilities tag is not intended to/cannot be exhaustive. There are vulnerable packages that lack this tag for two main reasons:

• No triage or awareness: No one has triaged or is aware of the issue yet. Detecting such packages should fall under the responsibility of the security tracker (see nix-local-security-scanner).
• Ecosystem-wide impact: The issue affects the entire ecosystem. While this is not ideal, we are not in a worse position than other distributions or package sets, and resolving it require work beyond the Nix ecosystem. These days we have the situation for packages like libxml2 and libxslt.

I do not believe in applying some sort of severity threshold to apply the tag. Properly assessing severity requires context and knowledge of specific use cases, which is difficult for us to determine from our position. While an unauthenticated root RCE is clearly more critical than an authenticated client-side ReDoS, such clear-cut cases are rare.
On the other side, there are also bogus issues that we should not burden users with (and, when they have a CVE ID, we should consider working with the CNA to reject it).

For end-of-life software, the general process should be in my opinion:

• Drop from unstable: We cannot maintain software that is no longer supported upstream.
• Tag with knownVulnerabilities on stable branches: We lack the capacity to maintain it or determine whether issues in supported versions also affect unsupported ones we might still provide (see also Node.js’ approach to EOL CVEs).
• Proactively drop soon-to-be-EOL versions: When possible, we should remove versions that will reach EOL before the end of the next stable cycle to minimize the workload for stable users during a cycle.

[SuperSandro2000]

@LeSuisse What are your points on people stopping to update because the software they need is no longer available or they can no longer compile it on their hardware? I had this with libsoup_2 and qtwebkit where people reached out to me after 2 weeks not updating and asking when this is going to be fixed and that they cannot update until then. I tried to convince them to comment out the software until it is fixed but that was not granted with success. Furthermore, I am very afraid that we are promoting not updating with those very aggressive approaches.

Proactively drop soon-to-be-EOL versions: When possible, we should remove versions that will reach EOL before the end of the next stable cycle to minimize the workload for stable users during a cycle.

This works very well when the software is going EOL within a few weeks and sometimes months after the release but very poor when it goes EOL at the very end of the release cycle like two weeks before it ends. Usually ecosystems have not caught up at this point and trying to convince upstream developers and maintainers to jump to the next version of something if they still have 5 months of support is not only stressful but also feels very demanding and creates for everyone a lot of artificial stress where we could just acknowledge those potential two weeks and accept it and have the next version in the next release cycle.

[Eveeifyeve]

There should be a policy when a package is unmaintained to add a knownVulenability that it's unmaintained like:

meta = {
knownVulnerabilities = [ "unmaintained" ];
maintainers = with lib.maintainers; [ ];
.....
}

I will look into implementing a draft policy for this and usage of knownVulnerabilities.

[mweinelt]

@Eveeifyeve https://github.com/NixOS/rfcs/blob/master/rfcs/0127-issues-warnings.md