<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Security Fixes on WordPress</title>
	<atom:link href="http://www.lostaddress.org/2006/03/12/security-fixes-on-wordpress/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.lostaddress.org/2006/03/12/security-fixes-on-wordpress/</link>
	<description>making our stupidity help you</description>
	<pubDate>Tue, 06 Jan 2009 08:07:49 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: hari</title>
		<link>http://www.lostaddress.org/2006/03/12/security-fixes-on-wordpress/comment-page-1/#comment-194</link>
		<dc:creator>hari</dc:creator>
		<pubDate>Tue, 14 Mar 2006 06:43:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.lostaddress.org/index.php/2006/03/12/security-fixes-on-wordpress/#comment-194</guid>
		<description>Yeah, I updated as well... Doesn't seem that too many files are updated. It would be nice if we could get the patched files list and update only those. Re-uploading the entire package every time seems a bit overkill.</description>
		<content:encoded><![CDATA[<p>Yeah, I updated as well&#8230; Doesn&#8217;t seem that too many files are updated. It would be nice if we could get the patched files list and update only those. Re-uploading the entire package every time seems a bit overkill.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ray</title>
		<link>http://www.lostaddress.org/2006/03/12/security-fixes-on-wordpress/comment-page-1/#comment-193</link>
		<dc:creator>Ray</dc:creator>
		<pubDate>Sun, 12 Mar 2006 21:57:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.lostaddress.org/index.php/2006/03/12/security-fixes-on-wordpress/#comment-193</guid>
		<description>While I accept, to a certain degree, what you are saying, I would say that the fact that you have to hunt around the bug tracker woulddissuade most of the WP users from finding out about it.  It's a pretty imperfect way of telling people that there's a problem.

I am a Linux user, which means that I expect to see announcements saying "&lt;em&gt;users of [software]-versionx.x should update to versionx.y because the following exploit will make your system vulnerable in this way&lt;/em&gt;"  The way WP chooses to do it does not make it safer (if I were a cracker, I &lt;em&gt;would&lt;/em&gt; look at the bug-tracker).  

Looking at the WP dashboard on my site, when 2.0.1 was released, there was a link to all the fixed things.  2.0.2 doesn't have this - compare http://wordpress.org/development/2006/01/201-release/ with http://wordpress.org/development/2006/03/security-202/</description>
		<content:encoded><![CDATA[<p>While I accept, to a certain degree, what you are saying, I would say that the fact that you have to hunt around the bug tracker woulddissuade most of the WP users from finding out about it.  It&#8217;s a pretty imperfect way of telling people that there&#8217;s a problem.</p>
<p>I am a Linux user, which means that I expect to see announcements saying &#8220;<em>users of [software]-versionx.x should update to versionx.y because the following exploit will make your system vulnerable in this way</em>&#8221;  The way WP chooses to do it does not make it safer (if I were a cracker, I <em>would</em> look at the bug-tracker).  </p>
<p>Looking at the WP dashboard on my site, when 2.0.1 was released, there was a link to all the fixed things.  2.0.2 doesn&#8217;t have this - compare <a href="http://wordpress.org/development/2006/01/201-release/">http://wordpress.org/development/2006/01/201-release/</a> with <a href="http://wordpress.org/development/2006/03/security-202/">http://wordpress.org/development/2006/03/security-202/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark J</title>
		<link>http://www.lostaddress.org/2006/03/12/security-fixes-on-wordpress/comment-page-1/#comment-192</link>
		<dc:creator>Mark J</dc:creator>
		<pubDate>Sun, 12 Mar 2006 20:25:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.lostaddress.org/index.php/2006/03/12/security-fixes-on-wordpress/#comment-192</guid>
		<description>&lt;a href="http://lists.automattic.com/mailman/listinfo/wp-trac" rel="nofollow"&gt;WP-Trac mailing list (bug tracking system)&lt;/a&gt;
&lt;a href="http://lists.automattic.com/mailman/listinfo/wp-hackers" rel="nofollow"&gt;WP-Hackers mailing list (some discussion of bugs, even security related, goes on here)&lt;/a&gt;
&lt;a href="http://lists.automattic.com/mailman/listinfo/wp-svn" rel="nofollow"&gt;WP-SVN mailing list (immediate notifications of changes to the code)&lt;/a&gt;

The "bug" (alleged security issue) actually &lt;strong&gt;was&lt;/strong&gt; fixed in 2.0.2 &lt;a href="http://trac.wordpress.org/changeset/3584" rel="nofollow"&gt;here&lt;/a&gt;... but that wasn't the reason for the update (because it wasn't a valid security concern).

As to what the update addresses:
SQL injection, XSS and CSF loopholes that were discovered internally, as well as a few miscelaneous non-security-related bugs (like the one in changeset 3584).

See &lt;a href="http://trac.wordpress.org/log/branches/2.0/" rel="nofollow"&gt;here&lt;/a&gt; for the whole list of what has changed in the 2.0 branch.

I understand your concern with regards to openness... but considering that there was no public knowledge of these security bugs (and thus, no instances of them being exploited), it wouldn't make sense to explicitly describe the security holes when the new version is offered.  That would only give the script kiddies a head start.  This way, the public knows that there are security issues being addressed, and that the upgrade fixes them, but any would-be exploiters have to actually work to figure out what they are.

It's not that the bugs are being hidden... they're there for everyone to see in the links I just provided... they're just not being advertised in explicit detail just yet.</description>
		<content:encoded><![CDATA[<p><a href="http://lists.automattic.com/mailman/listinfo/wp-trac">WP-Trac mailing list (bug tracking system)</a><br />
<a href="http://lists.automattic.com/mailman/listinfo/wp-hackers">WP-Hackers mailing list (some discussion of bugs, even security related, goes on here)</a><br />
<a href="http://lists.automattic.com/mailman/listinfo/wp-svn">WP-SVN mailing list (immediate notifications of changes to the code)</a></p>
<p>The &#8220;bug&#8221; (alleged security issue) actually <strong>was</strong> fixed in 2.0.2 <a href="http://trac.wordpress.org/changeset/3584">here</a>&#8230; but that wasn&#8217;t the reason for the update (because it wasn&#8217;t a valid security concern).</p>
<p>As to what the update addresses:<br />
SQL injection, XSS and CSF loopholes that were discovered internally, as well as a few miscelaneous non-security-related bugs (like the one in changeset 3584).</p>
<p>See <a href="http://trac.wordpress.org/log/branches/2.0/">here</a> for the whole list of what has changed in the 2.0 branch.</p>
<p>I understand your concern with regards to openness&#8230; but considering that there was no public knowledge of these security bugs (and thus, no instances of them being exploited), it wouldn&#8217;t make sense to explicitly describe the security holes when the new version is offered.  That would only give the script kiddies a head start.  This way, the public knows that there are security issues being addressed, and that the upgrade fixes them, but any would-be exploiters have to actually work to figure out what they are.</p>
<p>It&#8217;s not that the bugs are being hidden&#8230; they&#8217;re there for everyone to see in the links I just provided&#8230; they&#8217;re just not being advertised in explicit detail just yet.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
