Open yashrsharma44 opened 2 months ago
This is one of the points raised in https://github.com/google/osv.dev/blob/master/docs/data_quality.md#precise
I'm not aware of a way to programmatically make the linkage from (in this example) 0838d6d68182f0b28a5434bc6d50727c4757e35b to 926fd9f23b27ca6587492c3f58f4c7f4cd01dad5 and so this is currently a data quality issue on the originating record.
:sparkles: Thank you for your interest in OSV.dev's data quality! :sparkles:
Please review our FAQ entry on how to most efficiently have this addressed.
I'm not aware of a way to programmatically make the linkage from (in this example) 0838d6d68182f0b28a5434bc6d50727c4757e35b to 926fd9f23b27ca6587492c3f58f4c7f4cd01dad5 and so this is currently a data quality issue on the originating record.
Ohh great, I am glad that is a known issue.
While a rough idea in my mind, would be to map access the git message(maybe by downloading the message) and perform the mapping? But agree, without fetching the commit, it's difficult to get the mapping programmatically.
This issue has not had any activity for 60 days and will be automatically closed in two weeks
See https://github.com/google/osv.dev/blob/master/CONTRIBUTING.md for how to contribute a PR if you're interested in helping out.
Describe the bug
Hi Team,
I am playing with the OSV API for checking vulnerabilities in the kernel repositories, and on trying the cli, I got the following results -
Picking one the vulnerabilities from the output -
GSD-2022-1000409
, I wanted to check the commit hash which fixes the issue - https://osv.dev/vulnerability/GSD-2022-1000409 The solution fix (0838d6d68182f0b28a5434bc6d50727c4757e35b
) - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ doesn't lie in the given repository, and on checking the link, I see that it lies in an external fork - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0838d6d68182f0b28a5434bc6d50727c4757e35bThe commit message itself suggests that the fix is an upstream commit -
To Reproduce Provided above Expected behaviour The solution fix should lie in the upstream branch(or atleast should be present in the fork)
Screenshots
Additional context