Adding a narrative introduction to the testing security tracker

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

1 files changed, 239 insertions, 0 deletions

diff --git a/doc/narrative_introduction b/doc/narrative_introduction
new file mode 100644
index 0000000000..b0e1fe7fde
--- /dev/null
+++ b/doc/narrative_introduction
@@ -0,0 +1,239 @@
+	A Narrative Introduction to the Testing Security Tracker 
+
+
+About
+-----
+
+Everything that Testing Security does is publically available, as in
+"Debian doesn't hide problems" available. 
+
+The best thing about our tracking 'system' is that it is very basic.
+There is no horrible overhead of web-based ticket/issue trackers, its
+just a subversion repository and some text files that we
+collaboratively edit and then some scripts to parse these files and
+generate useful reports available online. Everything is designed to be
+very simple to use, transparant 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. Transparancy is what our
+users expect, and what they deserve. Tracking publically 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.
+
+Gentile 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.
+
+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
+at home. To do this, you need an Alioth account, and then you just
+need to do the following:
+
+svn co svn+ssh://svn.debian.org/svn/secure-testing
+
+This will check out our working repository into a directory called
+secure-testing. Inside this directory are a number of subdirectories.
+The data directory is where we do most of our work. 
+
+Automatic Issue Updates
+-----------------------
+Twice a day a cronjob runs that pulls down the latest full CVE lists
+from Mitre, this automatically gets checked into data/CVE/list. We get
+notified via either email
+(http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits)
+of every SVN commit, by RSS feed
+(http://svn.debian.org/wsvn/secure-testing/?op=rss&rev=0&sc=0&isdir=1)
+or via the CIA bot on #debian-security on OFTC. For example, the bot
+will say in the channel:
+
+17:14 < CIA-1> joeyh * r2314 /data/CVE/list: automatic CAN database update
+
+Most of our work is taking the new issues that Mitre releases and
+processing them so that the tracking data is correct. Read on for how we
+do this.
+
+Processing TODO entires
+-----------------------
+The Mitre update typically manifests in new CVE entries. So what we do
+is to update our svn repository and then edit data/CVE/list and look
+for new TODO entries. These will often be in blocks of 10-50 or so,
+depending on how many new issues they have assigned. Depending on how
+you feel you will "claim" a block of say 10 new entries by
+putting your name in the file at the beginning and the end of the new
+TODO entries and then commit the repository. This looks like this:
+
+begin claimed by jmm
+CVE-2005-4066 (Total Commander 6.53 uses weak encryption to store FTP
+usernams and ...)
+ 	TODO: check
+CVE-2005-4065 (SQL injection vulnerability in the search module in
+Edgewall Trac ...)
+ 	TODO: check
+CVE-2005-4030 (SQL injection vulnerability in Quicksilver Forums
+before 1.5.1 allows ...)
+ 	TODO: check
+end claimed by jmm
+
+Once these are checked-in, then others will not do work on these TODO
+issues. 
+
+Issues Not-For-Us (NFU)
+-----------------------
+Processing your claimed entires is done by first seeing if the issue
+is related to any software packaged in Debian, if it isn't a package
+in Debian and has no ITP then you note that in the file, for example:
+
+CVE-2005-3018 (Apple Safari allows remote attackers to cause a denial of
+service ...)
+   NOT-FOR-US: Safari
+
+
+ITP packages
+------------
+If it is a package that someone has filed an RFP or ITP for, then that
+is also noted, so it can be tracked to make sure that the issue is
+resolved before the package enters the archive:
+
+CVE-2004-2525 (Cross-site scripting (XSS) vulnerability in compat.php
+in Serendipity ...)
+        - serendipity <itp> (bug #312413)
+
+
+Packages in the archive
+-----------------------
+If it is a package in Debian you look to see if the package is
+affected or not (sometimes newer versions that have the fixes have
+already been uploaded). 
+
+If the version has been fixed already, note the package name and the
+Debian version that fixes it and assign a severity level to it, for
+example:
+
+CVE-2005-2596 (User.php in Gallery, as used in Postnuke, allows users
+with any Admin ...)
+   - gallery 1.5-2 (medium)
+
+If it hasn't been fixed, I will determine if there has been a bug filed
+about the issue, and if not, I will file one and then note it in the
+list (again with a severity level):
+
+CVE-2005-3054 (fopen_wrappers.c in PHP 4.4.0, and possibly other
+versions, does not ...)
+   - php4 <unfixed> (bug #353585; medium)
+   - php5 <unfixed> (bug #353585; medium)
+
+NOTE and TODO entries
+---------------------
+There are many instances where more work has to be done to determine
+if something is affected, and you might not be able to do this at the
+time. These entries can have their TODO line changed to something
+descriptive so that it is clear what remains to be done. For example:
+
+CVE-2005-3990 (Directory traversal vulnerability in FastJar 0.93
+allows remote ...)
+	TODO: check, whether fastjar from the gcc source packages is affected
+
+It is also useful to add information to issues as you find it, so that
+when others go to look at an issue and want to know why you marked it
+as you did, or need a reference, it will be there. The more
+information left, the better. For example, the following entry lets
+you know that CVE-2005-3258 doesn't affect the squid that we have
+because the issue was introduced in a patch that was never applied to
+the Debian package:
+
+CVE-2005-3258 (The rfc1738_do_escape function in ftp.c for Squid 2.5
+STABLE11 and ...)
+        - squid <not-affected> (bug #334882; medium)
+        NOTE: Bug was introduced in a patch to squid-2.5.STABLE10,
+        NOTE: this patch was never applied to the Debian package.
+
+
+TODO
+----
+
+Need to document [sarge], [woody], and other tags
+
+
+Generated Reports
+-----------------
+All of this tracking information gets automatically parsed and
+compared against madison to determine what has been fixed and what is
+still waiting, this results in this page:
+
+http://spohr.debian.org/~joeyh/testing-security.html
+
+This page tells us a number of things, for example:
+
+abiword 2.2.10-1 needed, have 2.2.7-3 for CAN-2005-2964
+
+This tells us that we know that this fix has been applied in debian
+package version 2.2.10-1, but testing only has 2.2.7-3. It has links to
+the reason why this hasn't entered testing yet, as well as the CAN
+reference at Mitre (given different background colors according to the
+severity). The ones with bugs have links directly to the bugs that have
+been filed. Additionally cross-references for DSAs are generated.
+
+At the bottom is a legend detailing the severity levels, the number of
+unfixed holes currently in testing, the number of holes that have been
+fixed in unstable that haven't migrated to testing, and the number of
+TODO items that we have to process still.
+
+TODO
+----
+Document Florian's tracker
+There is a more detailed tracker that is still under development, but
+provides a lot more views into this information, its here:
+http://idssi.enyo.de/tracker/
+
+
+Following up on security issues
+-------------------------------
+By simply loading this page and doing a little gardening of the
+different issues many things can be done. One thing is that you can
+read all the bug reports of each issue and see if new information has
+been added to the end that might provide updated or changed
+information (such as if an issue has been closed, or a version of the
+package has been uploaded that contains the fix). It is also useful to
+follow-up on the issues to prod the maintainer to deal with the issue,
+which they may have forgotten about.
+
+
+IRC Channel
+-----------
+We hang-out on #debian-security on OFTC, stop by the IRC channel if
+you'd like, also we can add you to the alioth project so you have svn
+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 severity levels
+document DSA/list
+document DTSAs
+document tsck