[15:35] <hank> Another bad date ("unknown") popped up in the OVAL XML for CVE-2022-32886 on 20.04
[15:37] <hank> would it be possible for the generator to attempt to parse the dates it creates?
[15:54] <ebarretto> hank, it could, but then what? this shouldn't stop the process from generating the data imho
[15:54] <ebarretto> I think this is something to be fixed in CVE generation, or avoided during CVE generation 
[15:59] <ebarretto> hank, what kind of issues is the date causing to you? 
[16:16] <hank> I mean, if the generator is producing a bogus date, that's something to alert on
[16:17] <hank> I ask because this has happened multiple times, and could be noticed during the generation process if it just tried to read what it creates
[16:18] <hank> the problem this causes to me is that my software is parsing the OVAL feed and erroring out because "unknown" isn't any sort of valid date
[16:27] <ebarretto> hank, the generator is not producing a bogus date, it comes from CVE file: https://git.launchpad.net/ubuntu-cve-tracker/tree/active/CVE-2022-32886 ... the OVAL data is still a valid one with this bogus date (oscap oval validate will succeed)
[16:28] <ebarretto> hank, which software are you using? 
[16:37] <ebarretto> my colleague fixed the CVE date status, should take a few hours to have this reflected in OVAL
[16:37] <ebarretto> I will personally take a look tomorrow on what is happening with the CVE generation to create this bogus date 
[16:53] <hank> Clair, but the code handling this is specifically https://github.com/quay/goval-parser/blob/master/oval/types.go#L134