CVE Feed: JSON feed should pass jsonfeed spec validator

[kevincox]

This is a Bug Report

The CVE Feed (https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json) is not valid JSON Feed (https://validator.jsonfeed.org/?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Freference%2Fissues-security%2Fofficial-cve-feed%2Findex.json)

Problem:

There are two problems listed:

1. One entry has an id of null. (IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements)
2. One entry has an external_url of null (IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements)
3. All entries are missing content (either content_text or content_html).

Proposed Solution:

1. Give it an ID.
2. Link to the GitHub issue.
3. Add some simple content such as a link to the GitHub issue.

Page to Update:
https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json

[sftim]

/sig security
/triage accepted

Part of the fix here will be about making sure that the upstream data are correct.

[sftim]

@kevincox I have lightly edited the issue description to highlight which fields are wrong.

/priority important-longterm

[reylejano]

cc: @PushkarJ

[mtardy]

We looked at it with Pushkar and as far as we understood the specification only allows for custom fields starting with an underscore. Search for "Extensions" in the spec, it seems that it's a bit restrictive (especially because any custom extension must be an object, not a string or a number).

So because people actually asked for other features, leading to adding arbitrary fields, we thought that maybe we could implement an RSS feed and keep a custom JSON object that does not follow the specification for now. So perhaps we can have the best of both worlds, an RSS feed for staying up to date and a JSON object for people that want a casual object to parse with a lot of info to retrieve.

[kevincox]

If you want custom data can't you just add something like _kubernetes.io: { /* whatever you want here */ }? That seems plenty flexible for me.

But I have no objection to switching to RSS (or Atom) either.

[mtardy]

Indeed you are correct, from the spec:

Also, it’s good practice to name an extension with a company or service name, to provide a clue right away as to what it’s for and who made it.

Further naming rules: the extension name and its member keys must not contain any. characters. The extension name, and only the extension name, must begin with an _ character. (No standard keys will ever begin with an _ — this is reserved for extensions.)

So it would be a good idea to use the kubernetes.io domain name as well, something without the dot.

But I have no objection to switching to RSS (or Atom) either.

Yes, maybe we could fulfill the RSS need + the feed thing without having to comply with JSON feed specifically. I actually don't know at all if it's a need to have a JSON feed, and if it's popular. I guess we could then choose the most simple way to implement a feed.

[kevincox]

I don't think JSON Feed is particularly popular (certainly far behind RSS and Atom) but I do think that it can serve as a dual-purpose for easy adding structured data in a way that developers are familiar with so they can easily access while combining with the well-speced semantics of a feed so that people can get general-purpose readers and tools to provide good results. I think it does make sense in this case to combine the two needs into one feed. However I think that two separate feeds, one generically consumable and one specific to Kubernetes is also a reasonable approach (although I would marginally recommend the former).

[PushkarJ]

/retitle CVE Feed: JSON feed should pass jsonfeed spec validator

(Added this in-scope for alpha to beta graduation)

[mtardy]

/assign

[sftim]

Fix LGTM