[Haifux] More information about latest OpenSSL/OpenSSH/OpenVPN vulnerabilities?

Shachar Shemesh shachar at shemesh.biz
Wed May 14 12:48:22 IDT 2008

Dotan Cohen wrote:
> 2008/5/14 Orr Dunkelman <orr.dunkelman at gmail.com>:
>> http://www.links.org/?p=327
> Lesson 1: Comment your code when doing something unusual  // for openssl
> Lesson 2: Patch upstream  // for debian
> Though in the beginning I blamed Debian for this mess, after reading
> that article I'm starting to see the fault as being with the unusual,
> uncommented code in openssl.

It should be noted that the problem was not with Debian removing the 
addition of entropy from uninitialized data to the entropy pool. The 
problem was that while removing that line, another line was removed, 
which added other entropy to the pool. As a result, no entropy was added 
at all.

Debian did ask upstream about this change, but the two upstream 
developers made two mistakes:
1. They did not say "this is an FAQ issue" 
(http://www.openssl.org/support/faq.html#PROG14). Two developers 
answered, one made a general comment (but did not point to the FAQ, or 
even say there was an FAQ about this)
2. They got carried away by the question, lumping the two lines together 
by mistake.

Then again, the Debian developer
1. Didn't mention that this was for a patch for Debian. He likely would 
have gotten more attention if he had
2. Didn't send an actual patch for upstream inclusion. Same as 1 above

If he had done 2, the patch would likely have been rejected. If it had, 
it would be likely that he would ask "why", and gotten an answer. That 
would, in turn, trigger him taking the code out of Debian before two 
years have passed.

Then again, many upstreams, when faced with a patch, merely ask "is it 
right for me". They do not think about downstream, or what the 
significance of someone from Debian sending in a patch (i.e. - that the 
patch is already in binaries elsewhere, even if not accepted here). As a 
result, not enough stress is given to rejections of patches from 
downstream (as opposed to rejection of regular patches).


More information about the Haifux mailing list