Jean-Baptiste Maillet

That looks interesting. Do you plan to do it in Vuls itself, or add it to CVE data in go-cve-dictionary? (Currently, I use only go-cve-dictionary from the Vuls.io stack: I...

> Thanks for the info, I didn't know it was 170MB. > I'm wondering how to integrate it because it's so huge. As I see it for now: - it...

Last for today: what I think I would and will do is a quick and dirty prototype (max 1 day of devel + 1 day or run on my products...

Another potential hard point I thought about trickest/cve: the data are in Markdown. While this is fine for human writing and reading, it has dialects, and does no have well...

Maybe playing MisterObvious, but IMHO the issue is not _version range_ or _version list_: the root cause of our headaches is version _computability_ (operators ==, , =), and while it...

(This is a long rant, but you can jump to the conclusion.) To give a bit of context to my comments, and self introducing: I work in the IoT/embedded field,...

@pombredanne , in my experience, on the kernel which is my hard case, there are: - 80% of CVE which are false positive per build configuration: buggy file(s) simply not...

> @jhutchings1 re: > > Thanks for advancing this draft @pombredanne ! Is there a world where we would want to require or recommend that a lowest common denominator version...

See also: https://github.com/vulsio/go-cpe-dictionary/issues/88 Any one could be considered a duplicate, but the issue must be considered at some point.

> One challenge is that the wrapper still need to produce output. Otherwise the build system (eg.: make) will not continue. Not really linked to the build time problem, but...