啊!再保险(CD): CD建议:SF-EXEC(软件缺陷在多个可执行文件)

>以下内容决定(CD)相关情况下的相同>软件缺陷出现在多个可执行文件在同一个>软件包。> > CD提议日期:6/12/2000 >投票期内:7/10/2000 >最终决定:7/24/2000 > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > CD: SF-EXEC(软件缺陷在多个可执行文件)> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >类型:抽象>版本:1.0 >提出:6/12/2000 >最终决定:N / > > > > >短描述- - - - - - - - - - - - - - - - - - > >如果相同的软件缺陷出现在多个可执行文件在同一个>包,然后记录在一个单独的条目。> > > > - - - - - - - - - - - - > >定义所有的定义都非正式。> >“软件包”是松散定义为一组软件>通常捆绑在一起,提供一个整体>功能,并提供了由一个供应商在同一平台,或为多个平台>相同的开发人员。我讨厌这张CD;感觉就像试图抓住湿玉米淀粉。你认为你有定义然后逃跑了。很多事情可以捆绑在一起——例如,微软的Word和Powerpoint在办公软件捆绑在一起。如果你不喜欢这个例子因为“单一功能”限定符,微软的Word安装包含“公式编辑器”和多个支持微软的Word的可执行文件。哪里这开始和停止吗? OS distributions? I see this as a continuum of possibilities with no clear boundaries in the middle. It would make more sense for me to specify that if you can't install something separately without losing its usefulness, then what it is a member of is a software package. A more fundamental problem with this CD is that you need to know all about the similar flaws in all of the executables before voting. The way things have been going, this could significantly delay the acceptance of candidates (information paralysis). Perhaps a solution would be to favor having a speedy CVE entry as the first (or first few) flaw is found, and having "append proposals" that would add to the initial CVE entry, as more information in the flaws of other executables is found. These "append proposals" could be useful in other situations as well, whenever a CVE entry needs updating (e.g., as new vulnerable versions are released). They should carry information that should not result in a new CVE entry. What if a vendor tries to fix all of them, but one of them escapes? You could find yourself in a situation where A says that they fixed CVE-xxxx-xxxx, B saying that it is still there, and scanning software C and D testing for the existence of this CVE vulnerability by different methods that yield opposite results. Another problem is the dependence on changing architectural and software engineering concepts that have to be reverse-engineered (read "guessed at") by us. It is also possible that in the future, these concepts will be obsolete. As an example (perhaps feeble), how would you characterize (classify?) code that is dynamically generated for you from outside your "PC" by a trusted source and then run on your machine, perhaps in a sandbox? Most likely, whether that (binary) code is from a "library", the same or a different "executable" will be transparent to you, and perhaps those concepts would be meaningless -- you subscribed to a "service". That code could be changed every day, perhaps even every time you change preferences. Would you then make a new CD? How do you deal with having to rebuild the CVE with a new CD, or having part of the database be defined by version 1 of a CD and another part defined by version 2? In conclusion, I feel that the less you need to know about a vulnerability to make a CVE entry, the better (aka the 'KISS' principle). This CD is mostly an attempt at optimization of the storage requirements of the CVE, that comes at too high a cost -- it comes close to a classification attempt. I think that this CD should not be adopted, and that we should avoid such complexity, delays and potential confusion as much as possible. Much of what I said here applies also to SF-LOC. "One entry per identifiable instance" Pascal "You cannot build a happy private life in a corrupt society anymore than you can build a house in a muddy ditch." Anonymous Czech woman, from the 2000 Commencement Address by Bill Moyers about the american political system