[AppStream] Adding CVE information to <releases>

[Matthias Klumpp]

Am So., 15. Sept. 2019 um 10:49 Uhr schrieb Richard Hughes
<hughsient at gmail.com>:
>
> On Sun, 15 Sep 2019 at 01:26, Matthias Klumpp <matthias at tenstral.net> wrote:
> > My initial impulse was something like this:
> >     <bugfix type="cve">CVE-2016-00000</bugfix>
> >     <bugfix type="url">https://bugzilla.redhat.com/show_bug.cgi?id=12345</bugfix>
>
> This needs a parent tag, although bugfix is more expressive than <issue>
>
> > But what if people want to mention issues fixed that aren't bugs, like
> > linking to features?
>
> I think that encroaches on the release notes URL.

That's the reason why I am a bit unsure about bugtracker links. CVEs
make sense because they can be processed by machines to query useful
information about the security status of updates and stuff installed
on the system, but bugtracker URLs are more to be read by humans as-is
(and in that case the details URL of release information may be the
better place to put them).

> >     <issues>
> >       <issue type="cve">CVE-2016-00000</issue>
> >       <issue type="url">https://bugzilla.redhat.com/show_bug.cgi?id=12345</issue>
> >     </issues>
>
> It does seem weird to have the "subject" of the CVE tag be the ID and
> the subject of the URL to be a, well, URL.
>
> > The name is okay. I dislike (bug)fix because it is less universal
>
> Also, bugfix implies there was a bug to begin with, which some legal
> teams don't like to admit -- this is why they're "issues" on GitHub
> for example.

Oh wow, that's a bit silly if that is indeed the case. I always
assumed it was called issues at Github because their tracker was
intended to be used for more than actual bugs.
Anyway, it looks like "issue" is definitely the right term then...

> [...]
> I think this is pretty close. CVE can have a URL too, for instance
> https://nvd.nist.gov/vuln/detail/CVE-2016-00000 -- given what we both
> agree on, there seems to be a few options:
>
> <issues>
>   <issue type="cve"
> url="https://nvd.nist.gov/vuln/detail/CVE-2016-00000">CVE-2016-00000</issue>
>   <issue url="https://bugzilla.redhat.com/show_bug.cgi?id=12345">RHBZ#12345</issue>
> </issues>

This ^ is the one I actually prefer, it is very in line with how the
AppStream spec generally outlines information like this in other
places.

> <issues>
>   <cve>CVE-2016-12345<cve>
>   <url>https://bugzilla.redhat.com/show_bug.cgi?id=12345</url>
> </issues>

This schema is used in AppStream only for relation types
(provides/recommends/requires/suggests) because each of the children
may have different properties depending on its type (e.g. the "dbus"
tag allows different types, while the "python3" tag doesn't). I don't
see this to be the case here.
Also from looking at it without prior knowledge I would actually
wonder what "url" belongs to (to the issues in general? to a
particular issue?). All other "url" tags in AppStream are in some way
associated with their parent node, like the component-related URL
types and the release-related details URl type.

> <issues>
>   <url type="cve"
> id="CVE-2016-00000">https://nvd.nist.gov/vuln/detail/CVE-2016-00000</url>
>   <url id="rhbz#12345">https://bugzilla.redhat.com/show_bug.cgi?id=12345</url>
> </issues>

I dislike this one because a CVE number may not have an associated
URL, yet the tag would be called "url" for some reason.

> I guess we've got to consider than metainfo.xml files are typically
> written by hand, and we ought to make the schema as simple as
> possible. Perhaps <cve>CVE-2016-12345<cve> is indeed the easiest thing
> to understand.

If we would only go with CVEs, I would agree. But learning from past
experiences, even if we wouldn't allow generic issue links now,
designing this feature to be extensible makes sense and will benefit
us in the long run (pretty much all deprecations in AppStream are due
to the initial solution not being designed in a way that was
extensible enough).

Cheers,
    Matthias

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