[AppStream] Adding CVE information to <releases>

[Matthias Klumpp]

Hi!

Am Sa., 14. Sept. 2019 um 09:09 Uhr schrieb Richard Hughes
<hughsient at gmail.com>:
>
> 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>

Yuck ^^
I actually always wanted to have this in AppStream and even once
drafted a spec addition, but for some reason never went through with
it...

> [...]
> 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.

I think this should definitely be more generic, but naming will be
hard on this one.
My initial impulse was something like this:
```
<releases>
  <release version="1.2.3" date="2018-02-10" urgency="low">
    <bugfix type="cve">CVE-2016-00000</bugfix>
    <bugfix type="url">https://bugzilla.redhat.com/show_bug.cgi?id=12345</bugfix>
  </release>
</releases>
```

I do not think a "bugzilla" type makes sense if the actual value of
the bugfix tag is an URL, so I think we are better off with an URL
there.
Putting bugfixes in their own section might also make sense.
But what if people want to mention issues fixed that aren't bugs, like
linking to features? In that case we would need to call this something
entirely different, like "issue" or "ticket" instead of bug, which
would result in something like this:
```
<releases>
  <release version="1.2.3" date="2018-02-10" urgency="low">
    <issues>
      <issue type="cve">CVE-2016-00000</issue>
      <issue type="url">https://bugzilla.redhat.com/show_bug.cgi?id=12345</issue>
    </issues>
  </release>
</releases>
```
I actually do like this, but a case could be made to have the type
property on the root <issues/> tag instead of on the children. But in
that case we would need to allow multiple <issues/> tags, which I
would really like to avoid (in that case we could just do away with it
and only have issue children under the release tag).
The name is okay. I dislike (bug)fix because it is less universal
compared to "issue" (which has synonyms like "problem", but also
"aspect" and "topic", although a native speaker can likely judge this
better than me), and I dislike "ticket" because it implies a specific
workflow and is a bit more confusing.

In general, I think at least CVE IDs make a lot of sense to have, and
having issue number URLs may be useful too. To make URLs more useful,
something like this may also work:
```
<issues>
  <issue type="cve">CVE-2016-00000</issue>
  <issue url="https://bugzilla.redhat.com/show_bug.cgi?id=12345">12345</issue>
</issues>
```
(a type of "url" being automatically implied if there is no type specified)
This would give UIs a string ID to make users click on to follow a
link (a non-translatable one, without much context though, unless
context was provided in the text - which is a case against doing this,
but at the same time, CVE IDs are also nonsensical until additional
information is fetched from the internet).

What do you think?

Cheers,
    Matthias

-- 
I welcome VSRE emails. See http://vsre.info/