<?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: Multiple Vendor DNS Cache Poisoning Vulnerability</title>
	<atom:link href="http://blog.pfsense.org/?feed=rss2&#038;p=209" rel="self" type="application/rss+xml" />
	<link>http://blog.pfsense.org/?p=209</link>
	<description>News, reviews and more related to the pfSense firewall project</description>
	<lastBuildDate>Wed, 22 May 2013 13:47:44 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: pfSense Digest &#187; Blog Archive &#187; Test dnsmasq available, fix for potential cache poisoning vulnerability</title>
		<link>http://blog.pfsense.org/?p=209&#038;cpage=1#comment-1554</link>
		<dc:creator>pfSense Digest &#187; Blog Archive &#187; Test dnsmasq available, fix for potential cache poisoning vulnerability</dc:creator>
		<pubDate>Thu, 10 Jul 2008 06:36:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pfsense.org/?p=209#comment-1554</guid>
		<description><![CDATA[[...] pfSense Digest News, reviews and more related to the pfSense firewall project      &#171; Multiple Vendor DNS Cache Poisoning Vulnerability [...]]]></description>
		<content:encoded><![CDATA[<p>[...] pfSense Digest News, reviews and more related to the pfSense firewall project      &laquo; Multiple Vendor DNS Cache Poisoning Vulnerability [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Buechler</title>
		<link>http://blog.pfsense.org/?p=209&#038;cpage=1#comment-1552</link>
		<dc:creator>Chris Buechler</dc:creator>
		<pubDate>Wed, 09 Jul 2008 22:33:45 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pfsense.org/?p=209#comment-1552</guid>
		<description><![CDATA[Ah, yeah the 1.2.1 and 1.3 upgrade systems are one click. Embedded is another story, that should be changing in 1.3 so it&#039;s a reliable one click as well. 

On the topic of this post - it doesn&#039;t appear dnsmasq is vulnerable to this, but given the lack of details the author isn&#039;t sure. There is a slightly improved version available that we will be making available as an update once we can properly test it.]]></description>
		<content:encoded><![CDATA[<p>Ah, yeah the 1.2.1 and 1.3 upgrade systems are one click. Embedded is another story, that should be changing in 1.3 so it&#8217;s a reliable one click as well. </p>
<p>On the topic of this post &#8211; it doesn&#8217;t appear dnsmasq is vulnerable to this, but given the lack of details the author isn&#8217;t sure. There is a slightly improved version available that we will be making available as an update once we can properly test it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill McGonigle</title>
		<link>http://blog.pfsense.org/?p=209&#038;cpage=1#comment-1551</link>
		<dc:creator>Bill McGonigle</dc:creator>
		<pubDate>Wed, 09 Jul 2008 19:48:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pfsense.org/?p=209#comment-1551</guid>
		<description><![CDATA[I&#039;m not sure we really need a differential update mechanism, per se - I only care about easy updates.  Currently, on some of my hardware I have a single flash card on an IDE adapter with pfSense on it, and no room in the box for a second.  To do a minor pfSense update I have to backup the config file, pull the thing out of the rack, unscrew the bottom cover, pull the card out, flash the card, put the card back in, put the screws in, rack it, configure a LAN interface, and then restore the config file.  This is a minor pain, but creates a good 15 minutes of downtime if I&#039;m fast with the screwdriver.  Yeah, I know, CARP a second one in, but still it would be lovely it it were easier.

I recall 1.3 gets us back the online updating mechanism - if that can preserve a config file, whether there&#039;s anything fancier is almost immaterial - I don&#039;t store any data on the box other than what&#039;s in my config.xml.  Sure, on a server I need yum, because there&#039;s a heck of a lot of data that can&#039;t get wiped out for a small update and the OS is gigabytes big.  But a 40MB download for a pfSense update I can do in a couple clicks? - no problem.]]></description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure we really need a differential update mechanism, per se &#8211; I only care about easy updates.  Currently, on some of my hardware I have a single flash card on an IDE adapter with pfSense on it, and no room in the box for a second.  To do a minor pfSense update I have to backup the config file, pull the thing out of the rack, unscrew the bottom cover, pull the card out, flash the card, put the card back in, put the screws in, rack it, configure a LAN interface, and then restore the config file.  This is a minor pain, but creates a good 15 minutes of downtime if I&#8217;m fast with the screwdriver.  Yeah, I know, CARP a second one in, but still it would be lovely it it were easier.</p>
<p>I recall 1.3 gets us back the online updating mechanism &#8211; if that can preserve a config file, whether there&#8217;s anything fancier is almost immaterial &#8211; I don&#8217;t store any data on the box other than what&#8217;s in my config.xml.  Sure, on a server I need yum, because there&#8217;s a heck of a lot of data that can&#8217;t get wiped out for a small update and the OS is gigabytes big.  But a 40MB download for a pfSense update I can do in a couple clicks? &#8211; no problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Buechler</title>
		<link>http://blog.pfsense.org/?p=209&#038;cpage=1#comment-1548</link>
		<dc:creator>Chris Buechler</dc:creator>
		<pubDate>Wed, 09 Jul 2008 07:19:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pfsense.org/?p=209#comment-1548</guid>
		<description><![CDATA[Yeah our current updating methodology does not provide differential updates, once an update is available you will have to use an update file with the entire OS, all applications and all the PHP code even though only dnsmasq will have changed. Technically if everyone was on 1.2 release we wouldn&#039;t have to release everything, just an update with only the dnsmasq fix. But since there are dozens of different versions in use, that isn&#039;t feasible with our existing update system. 

I don&#039;t think this will be on the road map for 1.3 because there are so many other great things we&#039;re adding and we only have so much time. This wouldn&#039;t have much of an impact on the user vs. the same amount of time spent on some other functionality that a lot of people can benefit from. Personally, wearing my end user hat, I don&#039;t care if the update is 40 MB or 2 MB. I would much rather that significant amount of time to provide differential updates be spent on improving functionality. It may change at some point in the future but likely not for 1.3.]]></description>
		<content:encoded><![CDATA[<p>Yeah our current updating methodology does not provide differential updates, once an update is available you will have to use an update file with the entire OS, all applications and all the PHP code even though only dnsmasq will have changed. Technically if everyone was on 1.2 release we wouldn&#8217;t have to release everything, just an update with only the dnsmasq fix. But since there are dozens of different versions in use, that isn&#8217;t feasible with our existing update system. </p>
<p>I don&#8217;t think this will be on the road map for 1.3 because there are so many other great things we&#8217;re adding and we only have so much time. This wouldn&#8217;t have much of an impact on the user vs. the same amount of time spent on some other functionality that a lot of people can benefit from. Personally, wearing my end user hat, I don&#8217;t care if the update is 40 MB or 2 MB. I would much rather that significant amount of time to provide differential updates be spent on improving functionality. It may change at some point in the future but likely not for 1.3.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: yosama</title>
		<link>http://blog.pfsense.org/?p=209&#038;cpage=1#comment-1547</link>
		<dc:creator>yosama</dc:creator>
		<pubDate>Wed, 09 Jul 2008 07:04:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pfsense.org/?p=209#comment-1547</guid>
		<description><![CDATA[would be a great feature addon for 1.3 if you guys could implement a package system for handling security updates, like yum, aptitude, or maybe use pkg_add (which already is in freebsd)

using a package manager we could easily update minor stuff without a full &quot;image&quot; install.]]></description>
		<content:encoded><![CDATA[<p>would be a great feature addon for 1.3 if you guys could implement a package system for handling security updates, like yum, aptitude, or maybe use pkg_add (which already is in freebsd)</p>
<p>using a package manager we could easily update minor stuff without a full &#8220;image&#8221; install.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
