We will be working on adding a report to each new update proposal that indicates if the update fixes (or introduces) security issues known to the Common Vulnerabilities and Exposures (CVE) system.
If you are also interested in supporting nixpkgs-update development and infrastructure, please consider contributing on Patreon.
Failed approach to add types to Nix raised $3k in few days, and working updater got $0…
It seems like people are willing to pay for empty promises than to something real.
I appreciate your support of and concern for nixpkgs-update! That Patreon page is new and wasn’t the main point of the post. It looks like only 10 people have clicked through to it so far. I don’t think this one link is close to comparable to the marketing done by the adding types project. In the future, I’ll do a dedicated fundraiser that I announce more broadly.
Wow, it has been a while since I posted an update about our progress on getting CVE reporting. Sorry about that!
@Lucus at Serokell has mostly finished making a program that downloads the National Vulnerability Database in a incremental way and loads it into a sqlite database for querying. He also worked on making it efficient to query if a version has CVEs associated with it, which is not trivial because CVEs can support multiple matching styles like exact matches and range matches.
Today, I made the basic CVE report that tries to match the Repology project name with the CVE project id, and I’m now running nixpkgs-update with this. Hopefully we’ll see some actual reports soon.
Here’s an example of how a report would have looked for a recently updated package that someone noticed had a CVE:
./result/bin/nixpkgs-update check-vulnerable bird 2.0.5 2.0.6
Experimental: CVE security report (click to expand)
CVEs resolved by this update:
- [CVE-2019-16159](https://nvd.nist.gov/vuln/detail/CVE-2019-16159)
CVEs introduced by this update:
none
CVEs present in both versions:
none
I’ve noticed that many of the CVE reports are obviously wrong, like the CVE report for tor is reporting CVEs for tor-browser. I’m noting wrong ones I find so we can go back and address them.
Which leads into the main issue left to address, which is the mapping of nixpkgs derivation/package to a Common Platform Enumeration (CPE). This is tricky to do automatically since different projects make use of different fields within the CPE. We will need to maintain a curated mapping from attrpaths to fix these issues. It would probably make sense to eventually incorporate this into the meta derivation information once we find a stable format.
There are also issues to resolve around the ordering of versions. There are a lot of different ways that projects represent release candidates and some projects change versioning schemes as they go, both of which make it hard to see where a version falls within a CVE version range match.
Please let me know if you have any feedback on our work!
Will it make any attempt to recognize patching or will we get nagged to bump the version of packages we’ve dutifully backported fixes to in the stable branch?
I’ve done some work on the matching front and I “suffered” from the same issues for https://broken.sh. If you feel like chatting about potential ways to fix/address/aid this kind of automatic matching hit me up on IRC (andi- @ freenode).
I do not have any immediate plans to recognize patches. Is there some standard patch format that is easy to tell addresses a CVE? It looks like some patches from Debian have the CVE number in the name.
nixpkgs-update does not consider the stable branch for anything it does, so it won’t be nagging about anything related to that.
It is possible that the report could note a CVE that was already patched, but I think a version update is a good time to look to see if the patches are still necessary.
I was just thinking about this - would it be possible for there to be a special property in the meta for declaring “no, really, it’s fixed for this”? Just a list of CVE ids at its simplest?
What vulnix currently does is inspect the patches drv attribute and scan for CVE identifiers in patch names. Although not perfect, it works well in many cases.
…though I can imagine cases where this would be an insufficient mechanism - another source of false positives is vulnerability databases having inaccuracies in their “versions vulnerable” information. This would provide no way of providing this information without having to put in a dummy/null “fix”.
@ris It’s not that bad anyway. Of course, patch name detection is a heuristic. But at least with vulnix, each CVE is reported only once for each unique combination of (pname, version, release). Given the fact that new releases often ship updated package versions, the amount of false positives should be manageable.
Well, there are certainly times I’ve named a patch CVE-1234-1234-partial.patch because it only patches e.g. some of the troublesome sites of a broader problem. See recent activity on ghostscript for instance.