再保险:cve - 2017 - 7269和过时的

>是的,这种情况下应该得到CVE id。我的问题是谁分配>,所以CNA规则/指导。第5页当前CNA规则状态:“在这种情况下,请求或由给定CNA问题不能解决,问题升级到下一个更高层次的中央社。”We may want to provide examples of the kinds of issues that might cause escalations, but I think this would cover it. > So the vendor CNA did not issue an ID, then the MITRE CNA did? Yes. > Requestor explicitly asks vendor CNA for an ID, vendor explicitly > says no or does not respond in a reasonable period of time, requestor > has email evidence to support this exchange? This sounds reasonable to me, though I figured others might want to discuss this a bit further. > And like G.I. Joe says "knowing is half the battle". Still bummed I never got the aircraft carrier toy as a kid. :-)http://www.yojoe.com/vehicles/85/ussflagg/克里斯- - - - - - - - - - -从原始信息:马尼恩艺术(mailto: amanion@cert.org发送:星期四,2017年3月30日11:01是:Kurt Seifried < kseifried@redhat.com >;棺材,克里斯< ccoffin@mitre.org > Cc: Landfield,肯特B < kent.b.landfield@intel.com >;cve-editorial-board-list < cve-editorial-board-list@lists.mitre.org >主题:Re: CVE 11 - 2017 - 7269和过时的2017-03-30 55,Kurt Seifried写道:>我知道事实我们有Linux是10年来的支持(EoL) >和仍在使用,如果有一个缺陷具体(而不是>新版本)我还是CVE如此至少人们意识到>缺陷的存在。就像g.i.j oe说“知道是>战斗的一半”。是的,这种情况下应该得到CVE id。我的问题是谁派他们,所以CNA规则/指导。>在星期四,2017年3月30日晚上,棺材,克里斯< ccoffin@mitre.org > <mailto: ccoffin@mitre.org> >中写道:> >我同意肯特的角度来看。我也是。>在这个特定的例子中,联系了CNA发现者和> >收到号码。然而,他们被告知>支持/过时>产品是CNA的范围之外。所以供应商CNA没有问题一个ID,然后横切CNA吗?> >是供应商CNA负主要责任,如果有的话?> >是的。我们应该给他们机会,重定向到> >如果他们存在。如果他们拒绝,那么下一个可用CNA > >可以联系。董事会讨论的一项,因为备份CNA >我们怎么确认这个对话发生。 Requestor explicitly asks vendor CNA for an ID, vendor explicitly says no or does not respond in a reasonable period of time, requestor has email evidence to support this exchange? - Art