再保险:JSON数据格式处理

2018年2月结婚,7日凌晨10:56,帕斯卡默< pmeunier@cerias.purdue.edu >写道:> > >库尔特,听起来不错,直到有人说base64编码的视频。我看到每个CVE入口> >在回购是一个单独的JSON文件。它是这些CVE >条目将>总是使用自己,在隔离?没有大小>限制可能使>一些不切实际的用例。即使你不打算使用>附加>字段,您支付的下载大小,服务时间或> >内存需求。添加更多的数据可能是有用的,但非常大> >也许应该更多的审查或适度的条目。我不断提高的原因之一,“我们需要定义字段大小和整体大小限制的极限”。> >如果额外的数据变得笨拙,将邀请>创建一个"瘦" >版本的CVE条目所需的最小数据,例如,用于>下载。是的。要记住的一件事是世界已经改变,我最小的设备啊. . 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> > > >这可能需要更改结束(例如,如果再生> >条目从他们的内部数据库如何我不清楚他们不关心更多> >数据/过程放回条目)。> > > > 2)我们董事会允许这样的实验,就像HTTP > >头,人们可以选择任意创建和使用他们,如果他们想要> >,然后如果东西是有用/广泛> >可以添加到规范(一般来说什么很好> >将采用广泛的成为一个有争议的问题)。> >——Kurt Seifried——红帽产品安全云PGP A90B F995 7350 148 f 66高炉7554 160 d 4553 7993 e26红帽产品安全联系:secalert@redhat.com