Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ