[AppStream] Adding CVE information to <releases>

[Richard Hughes]

Hi all,

On the LVFS we're using AppStream metadata to distribute information
about firmware updates. At the moment all the update description is
inside the <release> sections in a big <description> section. What
vendors have been doing is including the CVE information inline, for
instance;

- Firmware updates to address security advisories
INTEL-SA-00233(CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 and
CVE-2019-11091)

What I'd like to do instead is just have "Address security advisories
INTEL-SA-00233" in the description, and then have a separate section
for a list of CVEs. This way we can also cross reference which updates
fix which CVEs as at the moment we have to use full text searching
(regular expressions!) manually.

At the moment in the unreleased prototype I'm doing this:

  <releases>
    <release version="1.2.3" date="2018-02-10" urgency="low">
      <cves>CVE-2016-00000,CVE-2017-00000</cves>
    </release>
  </releases>

But this isn't very XMLy, or good design -- I'd like to be able to do
an XPath query for a specific CVE number. This isn't firmware
specific, I could also see this being used in normal desktop software,
or perhaps more usefully libraries if they ship metainfo.xml files.
Maybe I should propose something like this:

  <releases>
    <release version="1.2.3" date="2018-02-10" urgency="low">
      <cves>
        <cve id="CVE-2016-00000"/>
        <cve id="CVE-2017-00000"/>
      </cves>
    </release>
  </releases>

But I'm not 100% convinced I want to encode "cve" into the tag name. I
do want a parent tag (cves) so we can skip the (potentially long) list
of CVEs when scanning release versions when using a hierarchal engine
such as libxmlb.

Perhaps <fixes><fix type="cve">CVE-2016-00000</fix></fixes> is more
suitable. I guess that could be used to do something like <fix
type="bugzilla">https://bugzilla.redhat.com/show_bug.cgi?id=12345</fix>
which I don't know if it is a good or bad thing to put in AppStream
metadata.

Comments welcome, thanks.

Richard.