<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: debian and the openssl flaw</title>
	<link>http://baldric.net/2008/06/02/debian-and-the-openssl-flaw/</link>
	<description>another voice in the babble on the net</description>
	<pubDate>Fri, 05 Dec 2008 16:23:44 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>

	<item>
		<title>By: admin</title>
		<link>http://baldric.net/2008/06/02/debian-and-the-openssl-flaw/#comment-168</link>
		<author>admin</author>
		<pubDate>Thu, 05 Jun 2008 15:50:30 +0000</pubDate>
		<guid>http://baldric.net/2008/06/02/debian-and-the-openssl-flaw/#comment-168</guid>
		<description>Chris

I agree that Ben may have been indulging in a bit of post facto "face saving" as you say. But he has the decency to mention the openssl-dev list posting - embarrassing as that may be. But that still doesn't change my view that the upstream package maintainer is best placed to fix flaws. 

Both sides of the argument look bad here. The openssl team for not providing sufficient support to a query about the code (and for not commenting the code sufficiently well to allow the researcher to understand the impact of commenting out the "offending" lines); and the Debian team for making and then maintaining a fork of the openssl code for two years without getting it back into the upstream.  

Mick</description>
		<content:encoded><![CDATA[<p>Chris</p>
<p>I agree that Ben may have been indulging in a bit of post facto &#8220;face saving&#8221; as you say. But he has the decency to mention the openssl-dev list posting - embarrassing as that may be. But that still doesn&#8217;t change my view that the upstream package maintainer is best placed to fix flaws. </p>
<p>Both sides of the argument look bad here. The openssl team for not providing sufficient support to a query about the code (and for not commenting the code sufficiently well to allow the researcher to understand the impact of commenting out the &#8220;offending&#8221; lines); and the Debian team for making and then maintaining a fork of the openssl code for two years without getting it back into the upstream.  </p>
<p>Mick</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Samuel</title>
		<link>http://baldric.net/2008/06/02/debian-and-the-openssl-flaw/#comment-166</link>
		<author>Chris Samuel</author>
		<pubDate>Thu, 05 Jun 2008 02:46:25 +0000</pubDate>
		<guid>http://baldric.net/2008/06/02/debian-and-the-openssl-flaw/#comment-166</guid>
		<description>Hi Mick,

Whilst I am not happy with what happened here in Debian the patch in question was actually discussed on the openssl-dev list *before* being applied.   Ben now tries to claim that the openssl-dev list isn't for openssl development, but as this &lt;a href="http://lwn.net/Articles/282038/" rel="nofollow"&gt;LWN article points out&lt;/a&gt; the list was described on their site as:

&lt;blockquote&gt;&lt;em&gt;Discussions on development of the OpenSSL library. Not for application development questions!&lt;/em&gt;&lt;/blockquote&gt;

The list he suggested to be used was not mentioned on their website.  So I suspect there's a bit of face saving going on here on their part too.. :-)

Also don't forget that if you've used a compromised client with a good DSA key then you should consider that DSA key compromised as well. :-(</description>
		<content:encoded><![CDATA[<p>Hi Mick,</p>
<p>Whilst I am not happy with what happened here in Debian the patch in question was actually discussed on the openssl-dev list *before* being applied.   Ben now tries to claim that the openssl-dev list isn&#8217;t for openssl development, but as this <a href="http://lwn.net/Articles/282038/" rel="nofollow">LWN article points out</a> the list was described on their site as:</p>
<blockquote><p><em>Discussions on development of the OpenSSL library. Not for application development questions!</em></p></blockquote>
<p>The list he suggested to be used was not mentioned on their website.  So I suspect there&#8217;s a bit of face saving going on here on their part too.. :-)</p>
<p>Also don&#8217;t forget that if you&#8217;ve used a compromised client with a good DSA key then you should consider that DSA key compromised as well. :-(</p>
]]></content:encoded>
	</item>
</channel>
</rss>
