[Secure-testing-commits] r2991 - doc

[Moritz Muehlenhoff]

Author: jmm-guest
Date: 2005-12-09 12:21:23 +0000 (Fri, 09 Dec 2005)
New Revision: 2991

Modified:
   doc/narrative_introduction
Log:
very nice document, I've added a remark about read-only access to
our data and documented the severities. (I guess this was the concensus
we had at Oldenburg, feel free to change/amend, especially the people
who couldn't be present in OL).
I'll add a chapter about the [sarge] tags later in the train.


Modified: doc/narrative_introduction
===================================================================
--- doc/narrative_introduction	2005-12-09 10:34:13 UTC (rev 2990)
+++ doc/narrative_introduction	2005-12-09 12:21:23 UTC (rev 2991)
@@ -60,6 +60,11 @@
 secure-testing. Inside this directory are a number of subdirectories.
 The data directory is where we do most of our work. 
 
+If you don't need write access, you can of course check out our files
+without an Alioth account as well:
+
+svn co svn://svn.debian.org/svn/secure-testing
+
 Automatic Issue Updates
 -----------------------
 Twice a day a cronjob runs that pulls down the latest full CVE lists
@@ -147,6 +152,25 @@
    - php4 <unfixed> (bug #353585; medium)
    - php5 <unfixed> (bug #353585; medium)
 
+Severity levels
+---------------
+These levels are mostly used to prioritize the order in which security
+problems are resolved. Anyway, we have a rough overview on how you should
+assess these levels:
+
+unimportant: This problem does not affect the Debian binary package, e.g.
+             a vulnerable file, which is not built or a vulnerable file
+             in doc/foo/examples/
+low        : A security problem, which has only mild security implications
+             and one would even be comfortable with if it continues to
+             be present
+medium     : A typical, exploitable security problem.
+high       : A typical, exploitable security problem, which you'll really
+             like to fix and at least implement a workaround. This could
+             be because the vulnerable code is very broadly used, because
+             an exploit is in the wild or because the attack vector is
+             very wide.
+
 NOTE and TODO entries
 ---------------------
 There are many instances where more work has to be done to determine