[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JSON data format handling

On Wed, Feb 7, 2018 at 10:56 AM, Pascal Meunier
<pmeunier@cerias.purdue.edu> 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: secalert@redhat.com
Page Last Updated or Reviewed: February 09, 2018