Re: Historical analysis of pkg-vulnerabilities and remediation timelines

[kamel derouiche <kamelderouiche%yahoo.com@localhost>]

Hi Thomas,

Thanks for the feedback. This is very helpful.

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

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

Even brief pointers will help me isolate a robust subset of data for my empirical analysis.

Thanks again for your time,

Kamel

On Wednesday, October 28, 2026 at 07:05:08 AM GMT+1, kamel derouiche <kamelderouiche%yahoo.com@localhost> wrote:

Hi,

I am analyzing vulnerability tracking dynamics and remediation timelines within the pkgsrc ecosystem using the pkg-vulnerabilities database and its commit history.

To ensure accurate interpretation of the version control records, I would appreciate guidance on the following points:

1. CVS Completeness: Is the complete CVS history of pkgsrc/doc/pkg-vulnerabilities, including older revisions, fully preserved and reliable for historical reconstruction?

2. Lifecycle Tracking: Can the commit history be used to reliably extract the exact lifecycle of an entry-specifically its initial addition, modifications, and final removal?

3. Alternative Sources: Are there any legacy sources or local mirrors containing events missing from the public main mirror?

4. Timestamp Semantics: What does a commit timestamp on pkg-vulnerabilities represent operationally? Specifically, how does it correlate with the CVE publication date, triage by the security team, and the actual package patch date?

5. Removal Conventions: Are entries pruned exclusively when a package is fixed, or under other conditions? Can removals be reliably interpreted as remediation events?

6. Additional Archives: Are there internal logs or secondary datasets mapping these security events more directly?

My objective is to cleanly separate the disclosure timeline, the database record timeline, and actual package remediation without misinterpreting database updates.

Thank you.