diff options
author | Joey Hess <joeyh@debian.org> | 2005-09-04 15:26:25 +0000 |
---|---|---|
committer | Joey Hess <joeyh@debian.org> | 2005-09-04 15:26:25 +0000 |
commit | dd5614bd21451c224d9c2a1664c937741a1e07ab (patch) | |
tree | ddcecadadcaaa0c02707a418d941ebaefff18426 /doc/talks | |
parent | 439e643b898255b617bd4e87a93b79e1b142aab5 (diff) |
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
Diffstat (limited to 'doc/talks')
-rw-r--r-- | doc/talks/debconf5/testing-security.paper | 8 |
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 |