Re: Historical analysis of pkg-vulnerabilities and remediation timelines

[Leonardo Taccari <leot%NetBSD.org@localhost>]

Hello Kamel,

kamel derouiche writes:
> [...]
> To make sure I map the timelines correctly without relying on database update timestamps as strict proxies for remediation, I have two final, specific questions:
> 1. When a package is patched in pkgsrc, can the fix commit typically be cross-referenced reliably from the version-control history (e.g., via commit messages, CVE references, or concurrent updates to pkg-vulnerabilities)?

Unfortunately no. Some upstreams cites CVEs in their changelogs (and they
usually should ends up in commit messages), other not.
Similarly a package can be updated and the CVE fixed but
pkg-vulnerabilities is updated after several hours/days or even more.

> 2. Is there a standard convention or internal practice for explicitly linking a vulnerability database entry to the precise package commits that fix it?
> [...]

For pkg-vulnerabilities entries where the version patterns has < "nb"
(so a PKGREVISION bump happened) it's very likely that a commit fixed
that vulnerability and there was a PKGREVISION bump.
Similarly the case where the CVE is cited as part of the commit
message.
But also here there are no strict rules.

Apart pkg-vulnerabilities... As another complimentary datasource to
pkg-vulnerabilities maybe you can try to also give a look to CVE JSON
data at <https://github.com/CVEProject/cvelistv5> and in particular the
".containers.cna.affected.versions[]". If you find a "lessThan" in the
"versions" array when the "status" is "affected" it means that was
fixed at that "lessThan" version.
Unfortunately also here the quality of the data depends a lot on the
CNA (CVE Numbering Authority) that issued the CVE.


I hope this help!