q5sys
rschiron: any thoughts on closing out security tickets from 2016 that are from an EOL product?
rschiron
what if we needinfo the maintainer first so they get a chance to review?
i think trackers should be properly closed, otherwise those packages can be considered affected by a given CVE and we don't want packages affected by years old CVEs.
q5sys
Yup.  at #dayjob I use the Red Hat CVE list to check up on new issues.
rschiron
us closing them just because old enough can hide real things that were not fixed
q5sys
An example would be this one: https://bugzilla.redhat.com/show_bug.cgi?id=1370890
From 2016, an EOL'd product, and we dont ship the package anymore.
it might still be in the repo... IDK.
rschiron
i think we could use RH CVE API to get the "fixed in" version information, when available, and match that with the Fedora 36 version of the package and close when >=
q5sys
FWIW, I have zero plans to start making decisions unilaterally. I need to get up to speed on the SOPs for how things are handled for RH and F.  Whatever works best for the project and for RH is cool with me.
rschiron
or we could use the NVD API actually... might be more comprehensive
anyway, i believe it would be time better spent to do a small script trying to match affected versions rather than going 1 by 1 manually. there should be available information for the fixed version around and fedora mostly updates packages from upstream so it should be fine to just check those versions
jforbes
I think if it is a package that was orphaned and is not in any shipping version of Fedora, it can be closed. But there are plenty of packages with no changes other than mass rebuilds over several years too, so if we are shipping it, the fact that the CVE was 5 years ago doens't mean it is not valid
q5sys
 Agreed
rschiron
agree on both points
q5sys
Automating that would be great if it was done well.  I have experienced so much bad automation in my career that sometimes I think... "nah I'll do it manually". haha
Do you know where the RH CVE API is documented?  I dont think I've ever seen it... granted I've not really ever looked for it either... so maybe Im asking a dumb question.
rschiron
https://access.redhat.com/documentation/en-us/red_hat_security_data_api/1.0/html-single/red_hat_security_data_api/index
The Red Hat Security Data API exposes a list of endpoints to query security data with certain parameters and retrieve CVRF, CVE and OVAL data easily.
however, i'm not sure we should use that tbh... the "fixed" version is not something we collect consistently and maybe the NVD API might be better in this case
https://nvd.nist.gov/developers/vulnerabilities
q5sys
Out of curioisity, you all aren't doing something similar already with RHEL versions?
I kinda assumed you'd have everything possible automated.
rschiron
we have other kind of reminders for maintainers so things don't get forgotten indefinitely, but for RHEL is a bit harder to do something like this because there are backports usually
jforbes
Right, fixed version doesn't map directly for RHEL, nor does introduced, because the commits that introduced or fixed an existing vulnerability may or may not have been backported already
q5sys
makes sense