Re: cve - 2018 - 1000156应该拒绝吗?

增加董事会CC因为这引出一些highr水平的问题,我们可能需要考虑,在理想的情况下做出决定。

2018年在星期五,4月6日凌晨9:52,Theall,乔治<gtheall@mitre.org>写道:

嗨,库尔特,

(我接受了你的请求后,今天早上CVE - 2018 - 1000156,另一个横切CVE团队成员提出了一个担心CVE - 2018 - 1000156,问如果它应该被拒绝。)

这不幸的结果是Debian也给我们一个请求

昨天的问题”!'字符在补丁文件,

他们曾建议改变cve - 2015 - 1418不具体

FreeBSD。处理这个请求发生在你的面前

cve - 2018 - 1000156拉请求。所以,目前,我们有两个

密集的cf,指的是同样的问题在同一个版本的

GNU补丁:

http://cve.mitre.org/cgi-bin/cvename.cgi ? name = cve - 2015 - 1418

http://cve.mitre.org/cgi-bin/cvename.cgi ? name = cve - 20181000156

我们完全同意有多个版本的补丁

随着时间的推移分化。我们不确定具体影响的代码

的分歧需要多个cf。我们最初的想法是

重点是在pch do_ed_script函数。c文件,该文件

相同的代码结构,即使其他的不同

部分的代码库。

你想留在两个id在这一点上,或者你想要吗

拒绝cve - 2018 - 1000156代表分配CNA ?)

我认为它真的可以归结为我们如何定义通用代码基vs代码库分化。我喜欢合并的想法,因为一方面它让我们列出所有BSD, Linux, Mac OS(是的,容易受到这种)在一个CVE和做它,但是在这样特殊的情况下,我担心混乱由于时间表和BSD和Linux。(以及Mac OS的影响,我认为每一个变体与ed系统上的补丁,所以Solaris /等。应该测试)

我也担心它开创了一个先例”通用代码基”例如MySQL和所有的孩子,或其他年长的实用工具(如beep显然),有安全漏洞,并将有广泛不同数量的差异,我们可能首先要考虑。

也许我们应该看修改的内容决定不具体代码库具体还包括共同祖先如果这是一个概念性的问题(例如,代码是正确的,正是它是做设计的,它只是一个真正可怕的特性)。因此而不是“一个常见的补丁修复所有这些实现吗?如果是被视为共同的和合并”,但“一个容易定义解决方案(具体代码补丁,或特定的观念转变到代码)解决这个问题这些实现吗?如果是算共同和合并”。Thish在这种情况下,删除ed支持或使用ed - r (FreeBSD - r通过定义一个“红色”二进制,然后使用它)。

这当然会支持的想法“协议”水平缺陷,我忘了如果我们讨论了/来决定我们是否需要他们。

我们有点担心努力所需要的水平

维护多个cf command-injection类似问题

不同的人的副本do_ed_script pch.c函数

文件。例如,如果cve - 2015 - 1418只FreeBSD,和

cve - 2018 - 1000156只有GNU 2.7.6补丁,然后我们将

工作影响的其他代码维护者。实际上,他们

不是所有要费心去做CVE ID请求,不会和他们的用户

知道哪些(如果有的话)的CVE IDs应用。

我很好拒绝等等CVE - 2018 - 1000156支持freeBSD但我担心在这种情况下,它也可能是非常混乱,这就是为什么我做了新的CVE,但如果你认为合并是最好的,我们可以这样做。

乔治

- - -

gtheall@mitre.org

manbetx客户端首页

- - -

Kurt Seifried
kurt@seifried.org