various typo fixes and updates from Francesco Poli

git-svn-id: svn+ssh://svn.debian.org/svn/secure-testing@1803 e39458fd-73e7-0310-bf30-c45bca0a0e42

1 files changed, 4 insertions, 4 deletions

diff --git a/doc/talks/debconf5/testing-security.paper b/doc/talks/debconf5/testing-security.paper
index 7f7403bdbf..212d1c6a63 100644
--- a/doc/talks/debconf5/testing-security.paper
+++ b/doc/talks/debconf5/testing-security.paper
@@ -75,7 +75,7 @@ reaching testing in an appropriately fast time span for testing to be safe
 and secure.
 
   * Most security problems are release critical bugs, but if the package in
-    testing has additional release critical bugs besides the security fix,
+    unstable has additional release critical bugs besides the security fix,
     these can hold a crucial security fix out of testing indefinitely.
 
     The only way to avoid this is by back-porting the security fixes to the
@@ -230,7 +230,7 @@ security team, and also often one of the most tedious, as the majority of
 CVE entries are for software not in Debian, and some CVEs lack much useful
 information or are unlikely to really be security holes, and we have to
 check them manually, one at a time. Debian contains so many packages and
-there are enough different ways to write the name of a price of software
+there are enough different ways to write the name of a piece of software
 that it can involve quite a bit of checking just to see if a given piece
 of software is in the distribution. Also, many CVE items affect multiple
 packages in Debian due to code duplication and static linking, which can
@@ -383,7 +383,7 @@ testing first, and 19 (17%) did not affect software in testing.
 
 To track which holes are not fixed in unstable yet, and which holes have
 been fixed in unstable but have not reached testing, we use an
-[automatically updated list](http://newraff.debian.org/~joeyh/testing-security.html).
+[automatically updated list](http://spohr.debian.org/~joeyh/testing-security.html).
 
 This list includes a count of the numbers of each type of unfixed hole, and
 comparing these numbers is a useful (if flawed) metric to see if there is
@@ -393,7 +393,7 @@ place, or with getting the fix accepted into testing.
 Unfortunately historical data is not available for these numbers, however
 they have been roughly equal during most of this year, which suggests that
 on average approximately half of the time to fix a hole is spent in getting
-the hole fixed and into unstable, and half in getting the fix into testing.
+the hole fixed in unstable, and half in getting the fix into testing.
 
 One interesting consequence of this is that it might be a better use of the
 testing security teams's time to focus more effort on getting holes fixed