A couple of days ago I looked at p7zip and noticed that it’s basically unmaintained upstream and full of holes. Now I’m looking at libid3tag and… last upstream release 2004, multiple CVEs with patches floating around the internet. Just DOS, though.
Basically I’ve got a 100% hit rate when going through broken.sh right now for unmaintained upstreams.
So I’m wondering, what’s the correct time to deprecate software in nixpkgs?
Some small software projects may well be (mostly) feature complete with no important bugs and had their last release more than 10 years ago. That could be totally fine.
For other projects there is no developer anymore and the software has severall security critical bugs.
Where do we draw the line?
Do dependencies that other software have on that project influence our decision?
Personally I’d only mark dormant projects with a known CVE that isn’t fixed upstream and ignore how long there has not been a new release.
What’s your take on this? And is meta.knownVulnerabilities a good tag for this?
Personally I’d only mark dormant projects with a known CVE that isn’t fixed upstream and ignore how long there has not been a new release.
What’s your take on this? And is meta.knownVulnerabilities a good tag for this?
Sounds nice; improving the accuracy of knownVulnerabilities is an improvement in consistency of applying an already accepted practice; I guess there will be some bargaining about some low-severity CVE but that can be resolved on a case by case basis.
Personally I’d only mark dormant projects with a known CVE that isn’t fixed upstream and ignore how long there has not been a new release.
What’s your take on this? And is meta.knownVulnerabilities a good tag for this?
This sounds good to me. Might be coupled with “has been marked as broken
for at least X years without issues open in nixpkgs for it” for removal
even without known CVEs, as it probably means that no one cares about
the program any longer anyway.
I am against removing buggy old utilities (especially p7zip) but I am for
a marker in meta. Marking these packages as vulnerable gives us the
option to remove, but we could also potentially enforce that these
packages are only run in hardened or de-privileged sandboxes.
I don’t know what these sandboxes would look like, but I think puting
packages in different safety tiers is more pragmatic than kicking out
all the bad packages.
Removing software marked as broken is another thing, and should not be confused with “upstream does not exist anymore or doesn’t care”.
What I’m still unsure about is the issue with meta.knownVulnerabilities. Is that the right tag for a software for which we practically have no upstream and have to hunt for patches for future CVEs on random websites? After all it’s not necessarily a security vulnerability.
Should there be another flag similar to meta.broken? Something like meta.upstreamUnmainted?
That would mean that we don’t pollute knownVulnerabilities too much. Right now in the case of p7zip if someone whitelists the package and we later discover a real CVE that is not being fixed, we can add that to knownVulnerabilities, but it won’t show up for anyone using it.
