Re: JSON data format handling

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

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).
>