Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Feb 2014 20:28:02 +0530 (IST)
From: P J P <>
cc: oss security list <>
Subject: Re: CVE Request New-djbdns: dnscache: potential cache poisoning

+-- On Thu, 20 Feb 2014, 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.