Vulmon
On Thu, May 30, 2024 at 01:45:39PM +0900, Dominique Martinet wrote:
Very true, I do not claim to be a "robust" bash programmer at all :)
True.
Yeah, but the json files have their own issues, more below...
Great. Only you know your use cases, which is why we do not offer up
any "grading" of kernel CVEs as Linux is used in so many different ways.
The mbox files do get updated along with the json, but please, let's not
parse mbox files, that was a bad example I gave here, sorry.
That might be good, but really, we already have the needed information
here with the tool that creates all of this 'dyad', in the scripts/
directory. The output of that should be _much_ easier to parse:
$ ./scripts/dyad be0384bf599c
# ./scripts/dyad version: efdbc505ff2f
# getting vulnerable:fixed pairs for git id be0384bf599cf1eb8d337517feeb732d71f75a6f
5.8:797047f875b5463719cc70ba213eb691d453c946:6.1.87:492337a4fbd1421b42df684ee9b34be2a2722540
5.8:797047f875b5463719cc70ba213eb691d453c946:6.6.28:cba376eb036c2c20077b41d47b317d8218fe754f
5.8:797047f875b5463719cc70ba213eb691d453c946:6.8.7:49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b
5.8:797047f875b5463719cc70ba213eb691d453c946:6.9:be0384bf599cf1eb8d337517feeb732d71f75a6f
That tool generates a list of "vulnerable:fixed" pairs of version and
git ids. I have thought about checking in that output into the git repo
as odds are that would be easier than forcing you to regenerate it all
the time.
Here you see that the 5.10.y branch does not have a fix yet, and might
be easier than parsing the json files (which also show this), unless you
have a good json parser (i.e. something other than just bash.)
This output also catches where we introduce, and then fix, the issue in
the same release. dyad will show this, but as the issue never was in a
public release, CVE will not let us list it as that isn't relevent
there. But it IS relevent for those that might cherry-pick random
commits.
Sure, that would be great. Usually when a commit is NOT in an older
branch, that means it either did not apply, or it might be queued up for
the next release. Or sometimes, the stable developers just didn't know
it needed to be backported at the time. We probably should just sweep
the current ids and catch that last issue now to make it easier for
others going forward. I'll add that to my long todo list...
Agreed, or again, look at how dyad works, that might be simpler too, at
the expense that you have to compute it all the time, and it isn't the
quickest tool around (it's in bash and has not been optimized at all,
sorry.)
Yes, if we "know" when a specific fix actually is introduced, we can add
that to our tools to properly catch and mark the entries. That
information would be great to have.
Too true, there are very few of us actually working on this type of
thing, despite all of the people actually relying on it :(
Any help is greatly appreciated.
I will call out, we have had help from many developers from SuSE in
reviewing the current CVE entries and helping find duplicates and issues
we shouldn't have marked as such. And we have help from other
developers at other companies in doing reviews and seeing if commits
should, or should not, get CVE entries. All of that help is greatly
appreciated and we can always use more.
thanks,
greg k-h