Date: Thu, 20 Feb 2014 20:28:02 +0530 (IST) From: P J P <ppandit@...hat.com> To: cve-assign@...re.org cc: oss security list <oss-security@...ts.openwall.com> Subject: Re: CVE Request New-djbdns: dnscache: potential cache poisoning +-- On Thu, 20 Feb 2014, cve-assign@...re.org wrote --+ | However, lack of use of SipHash was not a "mistake." Almost any product can | be improved by addressing more classes of threats, but this does not | establish that a mistake occurred. So now SipHash is 'the only' way to avoid hash collision ever? | Those CVEs were based on announcements by vendors who were original | authors of pieces of software. Our first reply already mentioned that | those are an entirely separate case of CVE inclusion. So, if original author says it's a flaw then it's a flaw, otherwise not? | are, in general, a major complication for CVE. However, at this point, | keeping "algorithm-choice improvement after a fork" outside the scope | of CVE seems to be, on balance, the better alternative. That's not convincing, but anyways, I'm sure you know better than me. Thank you for the explanation. I appreciate it. Thank you. -- Prasad J Pandit / Red Hat Security Response Team
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ