JSON data format handling

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

JSON data format handling

Kurt Seifried
So long story shot:

The JSON data has a specification for the core required data:

https://github.com/CVEProject/automation-working-group/tree/master/cve_json_schema

This is the classic "minimum data needed to specify a CVE entry"

I am proposing that

1) any data outside of that specification be generally allowed, e.g.
if a vendor wants to add data about signatures for the vuln, or
whatever. Ideally MITRE should allow the data to be published in the
central CVE git repo at:

https://github.com/CVEProject/cvelist

this might require changes on their end (e.g. if the regenerate the
entries from their internal database I'm not clear on how the extra
data they don't care about/process is put back in to the entry).

2) We the board allow such experimentation, in that much like HTTP
headers, people can choose to arbitrary create, and consume them if
they want, and then if stuff turns out to be useful/widespread it can
be added to the specification (and in general anything really good
will be adopted widely making it a moot point).

--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: JSON data format handling

Pascal Meunier
Kurt, 

That sounds good until someone adds Base64-encoded video.  I see that each CVE entry
is a separate JSON file in the repo.  Is it the case that these CVE entries will
always be used by themselves, in isolation?  The absence of size limitations may make
some use cases impractical.  Even if you don't intend to consume the extraneous
fields, you pay for them in terms of download size, service time or memory
requirements.  Adding more data could be useful, but extremely large entries should
perhaps get more scrutiny or moderation.

If the additional data becomes unwieldy, that will invite the creation of a "skinny"
version of CVE entries with just the minimum data needed, e.g., for download purposes.

Pascal

On Tue, 2018-02-06 at 13:43 -0700, Kurt Seifried wrote:
> So long story shot:
>
> The JSON data has a specification for the core required data:
>
>

> This is the classic "minimum data needed to specify a CVE entry"
>
> I am proposing that
>
> 1) any data outside of that specification be generally allowed, e.g.
> if a vendor wants to add data about signatures for the vuln, or
> whatever. Ideally MITRE should allow the data to be published in the
> central CVE git repo at:
>
> https://github.com/CVEProject/cvelist
>
> this might require changes on their end (e.g. if the regenerate the
> entries from their internal database I'm not clear on how the extra
> data they don't care about/process is put back in to the entry).
>
> 2) We the board allow such experimentation, in that much like HTTP
> headers, people can choose to arbitrary create, and consume them if
> they want, and then if stuff turns out to be useful/widespread it can
> be added to the specification (and in general anything really good
> will be adopted widely making it a moot point).
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON data format handling

Kurt Seifried
On Wed, Feb 7, 2018 at 10:56 AM, Pascal Meunier
<[hidden email]> wrote:
> Kurt,
>
> That sounds good until someone adds Base64-encoded video.  I see that each CVE entry
> is a separate JSON file in the repo.  Is it the case that these CVE entries will
> always be used by themselves, in isolation?  The absence of size limitations may make
> some use cases impractical.  Even if you don't intend to consume the extraneous
> fields, you pay for them in terms of download size, service time or memory
> requirements.  Adding more data could be useful, but extremely large entries should
> perhaps get more scrutiny or moderation.

That's one of the reasons I keep raising the "We need to define the
limits of field sizes and the overall size limit".

>
> If the additional data becomes unwieldy, that will invite the creation of a "skinny"
> version of CVE entries with just the minimum data needed, e.g., for download purposes.

Yup. One thing to keep in mind is the world has changed, my smallest
device has uhh.. 64 gigs of storage? Obviously adding 1gig per CVE
times a few hundred cves is a problem, but in general the size
constraints are not what they once were (quantifying them them however
is another question, but probably something we should do sooner rather
than later).



> Pascal
>
> On Tue, 2018-02-06 at 13:43 -0700, Kurt Seifried wrote:
>> So long story shot:
>>
>> The JSON data has a specification for the core required data:
>>
>>
>
>> This is the classic "minimum data needed to specify a CVE entry"
>>
>> I am proposing that
>>
>> 1) any data outside of that specification be generally allowed, e.g.
>> if a vendor wants to add data about signatures for the vuln, or
>> whatever. Ideally MITRE should allow the data to be published in the
>> central CVE git repo at:
>>
>> https://github.com/CVEProject/cvelist
>>
>> this might require changes on their end (e.g. if the regenerate the
>> entries from their internal database I'm not clear on how the extra
>> data they don't care about/process is put back in to the entry).
>>
>> 2) We the board allow such experimentation, in that much like HTTP
>> headers, people can choose to arbitrary create, and consume them if
>> they want, and then if stuff turns out to be useful/widespread it can
>> be added to the specification (and in general anything really good
>> will be adopted widely making it a moot point).
>>



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]