3 ms·
I don’t think this is an unsolvable issue. Better naming conventions, or some kind of standardised util would do. $ patchinfo openssl 3.0.6 LTS Patches: Cve
by hsbauauvhabzb 4y ago
I don’t think this is an unsolvable issue. Better naming conventions, or some kind of standardised util would do.
$ patchinfo openssl
3.0.6 LTS
Patches:
Cve-2022-xxx
Cve-2022-xxx
Etc
- necovek 4y agoI do think it's unsolvable, since it's not a technical problem, but a societal one: Debian packages already list patched CVEs in their changelogs in a standardized format. Introducing a new tool will only add another on top of the existing tools, when nothing tells us that people will use it! (plug the xkcd on n standards -> fix with a better standard -> n +1 standards) Basically, you want to make everyone use a single tool when humans always strive to build something better or just different :) The best we could hope to achieve is to have the CVE MITRE database start accepting "patched in" strings from all the distributors (so as Ubuntu pushes a signed and patched package to the archive, it pings the CVE db with a new version string for eg. Ubuntu-22.04 namespace). Even that gets tricky with dependencies and issues covering multiple packages ("this is only patched if you've updated both of these"), though that's a technically solvable problem.
- hsbauauvhabzb 4y agoI agree with pretty much everything you said, but possibly a common metadata format (both our separate tools report differently but off the same data, etc). I also think that you’re probably right we the patched in, it’s not infinitely scalable, but I doubt it needs to be anyway