From ec8ae1a663eb5c2fe9e659cf46f33a1bb89af6de Mon Sep 17 00:00:00 2001 From: Moritz Muehlenhoff Date: Wed, 28 Oct 2009 20:24:59 +0000 Subject: separate introduction between the Debian Security Tracker and testing-security, it's confusing and we need a clean separation git-svn-id: svn+ssh://svn.debian.org/svn/secure-testing@13122 e39458fd-73e7-0310-bf30-c45bca0a0e42 --- doc/narrative_introduction | 62 ++++++++++++---------------------------------- 1 file changed, 16 insertions(+), 46 deletions(-) (limited to 'doc/narrative_introduction') diff --git a/doc/narrative_introduction b/doc/narrative_introduction index a09167f3bc..1f534ae67f 100644 --- a/doc/narrative_introduction +++ b/doc/narrative_introduction @@ -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 @@ generate useful reports available online. Everything is designed to be 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 @@ svn co svn+ssh://@svn.debian.org/svn/secure-testing 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 @@ is a list of packages for which each CVE should be reported separately: - 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 @@ CVE assignments 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 - and include a description which follows CVE + 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 @@ thus be used to - 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 @@ it hit stable. 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 @@ 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 DTSAs -document tsck -document tracked tag -- cgit v1.2.3