[Secure-testing-commits] r13122 - doc

Wed Oct 28 20:24:59 UTC 2009

Author: jmm-guest
Date: 2009-10-28 20:24:59 +0000 (Wed, 28 Oct 2009)
New Revision: 13122

Added:
   doc/narrative_introduction-testing-security
Modified:
   doc/narrative_introduction
Log:
separate introduction between the Debian Security Tracker and
testing-security, it's confusing and we need a clean separation


Modified: doc/narrative_introduction
===================================================================

--- doc/narrative_introduction	2009-10-28 20:17:12 UTC (rev 13121)
+++ doc/narrative_introduction	2009-10-28 20:24:59 UTC (rev 13122)
@@ -1,10 +1,10 @@
-	A Narrative Introduction to the Testing Security Tracker 
+	A Narrative Introduction to the Debian Security Tracker 
 
 
 About
 -----
 
-Everything that Testing Security does is publicly available, as in
+Everything in the Debian Security Tracker is publicly available, as in
 "Debian doesn't hide problems" available. 
 
 The best thing about our tracking 'system' is that it is very basic.
@@ -15,39 +15,11 @@
 very simple to use, transparent and easy to see what other people are
 working on so you can work on other things.
 
-Why are these issues disclosed to the public?
-
-The way we look at it is that 99% of all vulnerabilities are already
-public, and 1% are vendor-sec/embargoed issues.
-
-Stable security deals with embargoed/vendor-sec issues, we don't, we
-deal with issues that have already been assigned CVE numbers (although
-we often times request these assignments), have been posted to common
-security mailing lists, or are seen in commit logs of software that is
-tracked (such as the Linux Kernel).
-
-It is our philosophy that if the Internet knows that there is a
-vulnerability in something, then we better know about it and the
-package maintainer needs to know about it and it needs to be fixed as
-soon as possible. It doesn't make sense to hide issues that everyone
-knows about already, in fact users have told us that they prefer to
-know not only when a package they have installed is vulnerable (so
-they can disable it or firewall it off, or patch it or whatever), but
-to also know that Debian is working on a fix. Transparency is what our
-users expect, and what they deserve. Tracking publicly known issues
-openly (and the occasional unfortunate embargoed issue privately) is
-good for the project as a whole, especially the public's perception of
-the project.
-
 Gentle Introduction
 --------------------
 
 This following will give you a basic walk-through of how the files are
-structured and how we do our work tracking issues. There is much more
-that can be documented, but it is difficult to get all the issues
-notated and updated. It is easier to get a basic idea and then
-extrapolate from there how to do the rest. Ok, thats a bad excuse, so
-the full information should be filled in.
+structured and how we do our work tracking issues. 
 
 The best way to understand is to check out our repository from
 subversion so you have the files on your computer and can follow along
@@ -59,9 +31,11 @@
 This will check out our working repository after asking for your alioth
 password twice. This is normal and to be expected. After successfully
 downloading, you will have a new directory called 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 have an Alioth account, you
-can create one at:
+this directory are a number of subdirectories. The name of the Subversion
+repository is historical, the tracker is not specially related to
+testing-security, but for Debian security at large.
+The data directory is where we do most of our work. If you don't have
+an Alioth account, you can create one at:
 
 https://alioth.debian.org/account/register.php
 
@@ -254,7 +228,8 @@
     - php5
 
 A special exception is made for kernel related issues. The kernel-sec
-group will take care of them and file bugs if needed.
+group will take care of them. If not necessary to file bugs in the BTS
+for kernel security issues, it only causes overhead.
 
 If you wan't to report a bug, bin/report-vuln might be helpful in creating
 the bug report.
@@ -372,7 +347,7 @@
 
 Debian can only assign CVE names from its own pool for issues which
 are not public.  To request a CVE from the Debian pool, write to
-<security at debian.org> and include a description which follows CVE
+<team at security.debian.org> and include a description which follows CVE
 conventions.  To request a CVE for public issues, write to Mitre and
 possibly to the moderated oss-security list.  In the meantime, you can
 add an entry of the form
@@ -424,8 +399,8 @@
 - Present the security history of a package
 - Provide overviews of vulnerable packages in stable, testing, sid and
   oldstable (it still has some false positives, wrt packages in
-  stable that are present in stable, but not vulnerable, but these
-  will be ironed out soon). The oldstable data is likely inaccurate.
+  stable that are present in stable, but not vulnerable, these need to
+  be triaged individually).
 - Generate a list of packages that are subject to security problems, but
   stuck in testing migration due to problems with the dependency chain
   and thus candidates for a DTSA
@@ -471,12 +446,13 @@
 
 There is no need to add anything to CVE/list for a DSA, the DSA
 cross-reference will be added automatically by the cron job. However,
-you do need to add [sarge] or [woody] entries to CVE/list when there
+you do need to add [etch] or [lenny] entries to CVE/list when there
 is a 'no-dsa' or 'not-affected' condition.
 
 The bin/dsa2list script can be used to generate a template for a new
 DSA entry once the official DSA is published on debian-security-announce.
-You should not blindly trust the script output and double-check it, though.
+There is a script running, which automatically commits them to DSA/list.
+In some cases it needs manual fixups.
 
 Checking your changes
 ---------------------
@@ -529,9 +505,3 @@
 write permission and you can test drive it on the testing issues for
 however long you like to get an idea or feel comfortable (and hey it
 helps!)
-
-
-TODO:
-document DTSAs
-document tsck
-document tracked tag

Added: doc/narrative_introduction-testing-security
===================================================================
--- doc/narrative_introduction-testing-security	                        (rev 0)
+++ doc/narrative_introduction-testing-security	2009-10-28 20:24:59 UTC (rev 13122)
@@ -0,0 +1,23 @@
+	A Narrative Introduction to the Testing Security
+
+Stable security deals with embargoed/vendor-sec issues, we don't, we
+deal with issues that have already been assigned CVE numbers (although
+we often times request these assignments), have been posted to common
+security mailing lists, or are seen in commit logs of software that is
+tracked (such as the Linux Kernel).
+
+It is our philosophy that if the Internet knows that there is a
+vulnerability in something, then we better know about it and the
+package maintainer needs to know about it and it needs to be fixed as
+soon as possible. It doesn't make sense to hide issues that everyone
+knows about already, in fact users have told us that they prefer to
+know not only when a package they have installed is vulnerable (so
+they can disable it or firewall it off, or patch it or whatever), but
+to also know that Debian is working on a fix. Transparency is what our
+users expect, and what they deserve. Tracking publicly known issues
+openly (and the occasional unfortunate embargoed issue privately) is
+good for the project as a whole, especially the public's perception of
+the project.
+
+TODO:
+document DTSAs


