audit: Remove VuXML from audit and add OSV code

[illuusio]

Remove VuXML from code and add OSV JSON code. Code makes sure that there should be drop-in placement compatibility.

Before merging there should be ready:

• VuXML code remove
• OSVf reading and checking
• Update pkg config keys (OSVF_SITE and VUXML_SITE)
• Update Testcases for pkg audit
• Remove not needed external/yxml as it not anywhere than pkg_audio.c
• Update OSV schema validation to have correct released osv-schema.
• OSV FreeBSD vulnerability database released
• Change testing OSVF_SITE url to correct one

Testing OSV database can be found from: freebsd-osv.json

As FreeBSD OSV database ain't yet release this commit is WIP and should not be merged.

[illuusio]

Rebased to latest version. Ported old VuXML tests as they were so they are converted form XML to JSON and all they pass.

[decke]

I couldn't figure out which data the code uses to find a match. When looking at the freebsd-osv.json feed it seems to be package name. Is that correct?

I am currently working on improving CPE data in the portstree and I am not sure how that might fit into the picture. The basic idea behind CPE was to allow matching CVEs to software products and my naive understanding was that CPE will help us getting rid of manually crafting VUXML entries. What do you think about CPE_STR?

(sorry this is not an actual review but just me trying to understand the chosen solution and the consequences)

[illuusio]

I couldn't figure out which data the code uses to find a match. When looking at the freebsd-osv.json feed it seems to be package name. Is that correct?

I am currently working on improving CPE data in the portstree and I am not sure how that might fit into the picture. The basic idea behind CPE was to allow matching CVEs to software products and my naive understanding was that CPE will help us getting rid of manually crafting VUXML entries. What do you think about CPE_STR?

(sorry this is not an actual review but just me trying to understand the chosen solution and the consequences)

There is actually basic CPE string creation and parsing in pkg which I have committed last year (libpkg/pkg_cpe.c) so I like to CPE strings to rule things. If I understood correctly question was should CPE_STR use to determine bug? I don't have strong opinion but it would be better than current uuid (yes they are good to unique string but for humans they are just bad). I don't know if this is the place to have this conversation? If you ask me VuXML should be dropped and JSON OSV should be favored.

What comes to matching. pkg uses package name for matching this which makes things bit difficult to have CPE -> Vulnerability report converting as they can be very different than CPE strings are. WARNING THIS MY OPINION! If CPE is wanted to use there should be CPE name in package for matching (better would have CPE string for seeking) but I'm just man from bus station with out any needed knowledge about this.