From: Petter Reinholdtsen Date: Fri, 28 Jan 2011 21:10:17 +0000 (+0000) Subject: Generated. X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/576e8be428a68066ae35913f959bc287f0bd59ff 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 3e66f24b32..2eb51f028c 100644 --- 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 -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.

-

After reading up on the issue, it became obvious that the first +

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 diff --git a/blog/archive/2011/01/01.rss b/blog/archive/2011/01/01.rss index 31ce018fe3..dc639269e9 100644 --- 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 -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> -<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 diff --git a/blog/archive/2011/01/index.html b/blog/archive/2011/01/index.html index 55d3458997..63fdc9c825 100644 --- 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 -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.

-

After reading up on the issue, it became obvious that the first +

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 diff --git a/blog/index.html b/blog/index.html index 0601b1ebd7..5a9702779a 100644 --- 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 -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.

-

After reading up on the issue, it became obvious that the first +

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 @@ -1017,7 +1017,7 @@ servere.

-Created by Chronicle v3.2 +Created by Chronicle v3.7

diff --git a/blog/index.rss b/blog/index.rss index ef6296058f..dc52d68cb3 100644 --- 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 -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> -<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 diff --git a/blog/sitemap.xml b/blog/sitemap.xml index e235b62034..7041f88eba 100644 --- a/blog/sitemap.xml +++ b/blog/sitemap.xml @@ -930,6 +930,11 @@ 0.50 weekly + + http://people.skolelinux.org/pere/blog/Using_NVD_and_CPE_to_track_CVEs_in_locally_maintained_software.html + 0.50 + weekly + http://people.skolelinux.org/pere/blog/Vinmonopolet_bryter_loven___penlyst___og_flere_planlegger____gj__re_det_samme.html 0.50 diff --git a/blog/tags/debian/debian.rss b/blog/tags/debian/debian.rss index f64f6266af..6aa55952cb 100644 --- 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 -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> -<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 diff --git a/blog/tags/debian/index.html b/blog/tags/debian/index.html index 7dc7e2b78d..233491b992 100644 --- 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 -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.

-

After reading up on the issue, it became obvious that the first +

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 diff --git a/blog/tags/english/english.rss b/blog/tags/english/english.rss index 0cf69e1bc2..6b2023c263 100644 --- 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 -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> -<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 diff --git a/blog/tags/english/index.html b/blog/tags/english/index.html index 48acc1aace..2ec3b228e7 100644 --- 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 -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.

-

After reading up on the issue, it became obvious that the first +

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 diff --git a/blog/tags/sikkerhet/index.html b/blog/tags/sikkerhet/index.html index 5a3fcd43c6..c664017dec 100644 --- 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 -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.

-

After reading up on the issue, it became obvious that the first +

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 diff --git a/blog/tags/sikkerhet/sikkerhet.rss b/blog/tags/sikkerhet/sikkerhet.rss index 733fbbdd2a..16ae0fb2c7 100644 --- 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 -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> -<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