[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
