From: Petter Reinholdtsen
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