Generated.

diff --git a/blog/Using_NVD_and_CPE_to_track_CVEs_in_locally_maintained_software.html b/blog/Using_NVD_and_CPE_to_track_CVEs_in_locally_maintained_software.html
index 3e66f24b32639a4c4e8a3ccd339c6156fd631c27..2eb51f028c1ff626582ae43f51426c056a13cafd 100644 (file)
--- a/blog/Using_NVD_and_CPE_to_track_CVEs_in_locally_maintained_software.html
+++ b/blog/Using_NVD_and_CPE_to_track_CVEs_in_locally_maintained_software.html
@@ -25,14 +25,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs

diff --git a/blog/archive/2011/01/01.rss b/blog/archive/2011/01/01.rss
index 31ce018fe312c2e58fe957790559977ac2178075..dc639269e9c4b29306a418444b4efec01f439097 100644 (file)
--- a/blog/archive/2011/01/01.rss
+++ b/blog/archive/2011/01/01.rss
@@ -1295,14 +1295,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs

diff --git a/blog/archive/2011/01/index.html b/blog/archive/2011/01/index.html
index 55d345899719c5d1bda3155daacac303c5463197..63fdc9c825c23b0cbee2f0951d175de025da4b51 100644 (file)
--- a/blog/archive/2011/01/index.html
+++ b/blog/archive/2011/01/index.html
@@ -1508,14 +1508,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs

diff --git a/blog/index.html b/blog/index.html
index 0601b1ebd7c0c0264df164441dff0177b6f6462a..5a9702779a1b7774f9b1bc41790523b12cb613d4 100644 (file)
--- a/blog/index.html
+++ b/blog/index.html
@@ -28,14 +28,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs


@@ -1017,7 +1017,7 @@ servere.</p>
 </div>
 
 <p style="text-align: right">
 </div>
 
 <p style="text-align: right">

-Created by <a href="http://steve.org.uk/Software/chronicle">Chronicle v3.2</a>
+Created by <a href="http://steve.org.uk/Software/chronicle">Chronicle v3.7</a>

 </p>
 </body>
 </html>
 </p>
 </body>
 </html>

diff --git a/blog/index.rss b/blog/index.rss
index ef6296058f911491ca7ef072754e2b753f7f227d..dc52d68cb3abecec148e14126df9e9b7048bbd32 100644 (file)
--- a/blog/index.rss
+++ b/blog/index.rss
@@ -17,14 +17,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs

diff --git a/blog/sitemap.xml b/blog/sitemap.xml
index e235b62034bfd7b24dfaf48ac295022cbfcb4896..7041f88eba10f258e301831e7b65dad65cf7c967 100644 (file)
--- a/blog/sitemap.xml
+++ b/blog/sitemap.xml
@@ -930,6 +930,11 @@
   <priority>0.50</priority>
   <changefreq>weekly</changefreq>
  </url>
   <priority>0.50</priority>
   <changefreq>weekly</changefreq>
  </url>

+ <url>
+  <loc>http://people.skolelinux.org/pere/blog/Using_NVD_and_CPE_to_track_CVEs_in_locally_maintained_software.html</loc>
+  <priority>0.50</priority>
+  <changefreq>weekly</changefreq>
+ </url>

  <url>
   <loc>http://people.skolelinux.org/pere/blog/Vinmonopolet_bryter_loven___penlyst___og_flere_planlegger____gj__re_det_samme.html</loc>
   <priority>0.50</priority>
  <url>
   <loc>http://people.skolelinux.org/pere/blog/Vinmonopolet_bryter_loven___penlyst___og_flere_planlegger____gj__re_det_samme.html</loc>
   <priority>0.50</priority>

diff --git a/blog/tags/debian/debian.rss b/blog/tags/debian/debian.rss
index f64f6266af04099fb7ae18a5a748d8cfeb8beb79..6aa55952cb1a06de2fecc4dce6dbbc9ec726c0bc 100644 (file)
--- a/blog/tags/debian/debian.rss
+++ b/blog/tags/debian/debian.rss
@@ -3169,14 +3169,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs

diff --git a/blog/tags/debian/index.html b/blog/tags/debian/index.html
index 7dc7e2b78dc56b70680987fedc6e3e5c3e5d0af3..233491b992fe5db81ba0a20bdc3f26ff9f30e089 100644 (file)
--- a/blog/tags/debian/index.html
+++ b/blog/tags/debian/index.html
@@ -3799,14 +3799,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs

diff --git a/blog/tags/english/english.rss b/blog/tags/english/english.rss
index 0cf69e1bc286d4105792bca607636ed8a9f3c2ee..6b2023c263aedb652077715666a12040a3c20aa4 100644 (file)
--- a/blog/tags/english/english.rss
+++ b/blog/tags/english/english.rss
@@ -6011,14 +6011,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs

diff --git a/blog/tags/english/index.html b/blog/tags/english/index.html
index 48acc1aace8fc92dfd3dfc4082fb307c4b7ddfbc..2ec3b228e73cd6c56b56103f11b6ff18857d872d 100644 (file)
--- a/blog/tags/english/index.html
+++ b/blog/tags/english/index.html
@@ -7135,14 +7135,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs

diff --git a/blog/tags/sikkerhet/index.html b/blog/tags/sikkerhet/index.html
index 5a3fcd43c6bfca1cc311ca525dcf93e545da002e..c664017dec2f8c5d3b66bc580712dddc19eaf9cf 100644 (file)
--- a/blog/tags/sikkerhet/index.html
+++ b/blog/tags/sikkerhet/index.html
@@ -1442,14 +1442,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs

diff --git a/blog/tags/sikkerhet/sikkerhet.rss b/blog/tags/sikkerhet/sikkerhet.rss
index 733fbbdd2a8a79a3f12bded2d5adba016880e278..16ae0fb2c79f0d6da3b51565c7bcfa2c447ba14a 100644 (file)
--- a/blog/tags/sikkerhet/sikkerhet.rss
+++ b/blog/tags/sikkerhet/sikkerhet.rss
@@ -1137,14 +1137,14 @@ issues here at my work with the University of Oslo.  My idea is that
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should
 it should be possible to use the information about security issues
 available on the Internet, and check our locally
 maintained/distributed software against this information.  It should

-allow us to verify that no known security issue are forgotten.  The
+allow us to verify that no known security issues are forgotten.  The

 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 
 CVE database listing vulnerabilities seem like a great central point,
 and by using the package lists from Debian mapped to CVEs provided by
 the testing security team, I believed it should be possible to figure
 out which security holes were present in our free software
 collection.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>After reading up on the topic, it became obvious that the first

 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs
 building block is to be able to name software packages in a unique and
 consistent way across data sources.  I considered several ways to do
 this, for example coming up with my own naming scheme like using URLs