Contents of /doc/narrative_introduction

        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.

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.

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. 

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
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

Reserved entries
----------------
Several security problems have coordinated dates of public disclosure,
i.e. a CVE identifier has been assigned to a problem, but it's not
public yet. Also, several vendors have a pool of CVE ids they can
assign to problems that are detected in their products. Such entries
are marked as RESERVED in the tracker:

CVE-2005-1432
        RESERVED

Rejected entries
----------------
Sometimes there are CVE assignments that later turn out to be duplicates,
mistakes or non-issues. These items are reverted and turned into REJECTED
entries:

CVE-2005-4129
        REJECTED

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)

Bug numbers can be added as in the example above. They are used to add
additional references for the overview page and the Security Bug Tracker
and they are parsed by a script that generates user tags "tracked" for the
user debian-security@lists.debian.org. This way you can generate a BTS
query for all issues in the BTS that are tagged "security" and are not
yet added to our tracker:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security;users=debian-security@lists.debian.org;exclude=tracked

If a vulnerability does not affect Debian, e.g. because the vulnerable
code is not contained, it is marked as <not-affected>:

CVE-2004-2628 (Multiple directory traversal vulnerabilities in thttpd 2.07 beta 0.4, ...)
        - thttpd <not-affected> (Windows-specific vulnerabilities)

<not-affected> is also used if a vulnerability was fixed before a
package was uploaded into the Debian archive.

Sometimes there are cases, where a vulnerability hasn't been fixed with
a code change, but simply by deciding that a package is that broken that
it needs to be removed from the archive entirely. This is tracked with
the <removed> tag:

CVE-2005-1435 (Open WebMail (OWM) before 2.51 20050430 allows remote authenticated ...)
        - openwebmail <removed>


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 source 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 or 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
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.

Distribution tags
-----------------
Our data is primarily targeted at sid, as we track the version that
a certain issue was fixed in sid. The Security Tracker web site (see
below) derives information about the applicability of a vulnerability
to stable and oldstable from the list of DSAs issued by the security
team and the fact that a source package is part of a release.
Distribution tags can be used to denote information about a vulnerability
for the version of a package in a specific release. An example:

CVE-2005-3974 (Drupal 4.5.0 through 4.5.5 and 4.6.0 through 4.6.3, when running on ...)
        - drupal 4.5.6-1 (low)
        [sarge] - drupal <not-affected> (Only vulnerable if running PHP 5)

Drupal has been fixed since 4.5.6, however Drupal from Sarge still isn't
vulnerable as the vulnerability is only effective when run under PHP 5,
which isn't part of Sarge.

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.


The DSA list
------------
We maintain a list of all DSA advisories issued by the stable security
team. This information is used to derive information about the state
of security problems for the stable and oldstable distribution. An
entry for a DSA looks like this:

[21 Nov 2005] DSA-903-1 unzip - race condition
        {CVE-2005-2475}
        [woody] - unzip 5.50-1woody4
        [sarge] - unzip 5.52-1sarge2
        NOTE: fixed in testing at time of DSA

The first line tracks the date, when a DSA was issued, the DSA
identifier, the affected source package and the type of vulnerability.
The second line performs a cross-reference to the entry in CVE/list
that maintains the state of the vulnerability in sid. Every entry that
is added like this to DSA/list is parsed by a script and automatically
added to CVE/list.  The next lines contain the fixes for stable and
optionally oldstable, addressed with distribution tags.  You may add
NOTE: entries freely, we use a NOTE entry for statistical purposes
that tracks, when a fix has reached testing relative to the time when
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
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 the web.  You should
not blindly trust the script output and double-check it, though.

The security bug tracker
------------------------
There is a more detailed tracker that provides a lot more views into this
information, its here:  
http://idssi.enyo.de/tracker/

It incorporates package lists and parses distribution lists and can
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.
- 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
- Generate a list of TODO issues that need to be adressed
- Generate a list of packages that will enter Debian soon and need to
  be checked for security problems
- Generate a list of provisional IDs that need to be turned into proper
  CVE entries
- Show some potential problems in the data pool (e.g. misspelled package
  names not found in the packages list, or potentially missing epochs)

For every security problem it displays
- The CVE information
- A severity assessment by NVD
- Cross references to DTSAs, DSAs and bugs in the BTS
- The status of a security problem in stable, oldstable, testing and sid
- Additional notes from our 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 DTSAs
document tsck
document CVE-XXXX
document tracked tag
1	micah	2985	A Narrative Introduction to the Testing Security Tracker
2
3
4			About
5			-----
6
7			Everything that Testing Security does is publically available, as in
8			"Debian doesn't hide problems" available.
9
10			The best thing about our tracking 'system' is that it is very basic.
11			There is no horrible overhead of web-based ticket/issue trackers, its
12			just a subversion repository and some text files that we
13			collaboratively edit and then some scripts to parse these files and
14			generate useful reports available online. Everything is designed to be
15			very simple to use, transparant and easy to see what other people are
16			working on so you can work on other things.
17
18			Why are these issues disclosed to the public?
19
20			The way we look at it is that 99% of all vulnerabilities are already
21			public, and 1% are vendor-sec/embargoed issues.
22
23			Stable security deals with embargoed/vendor-sec issues, we don't, we
24			deal with issues that have already been assigned CVE numbers (although
25			we often times request these assignments), have been posted to common
26			security mailing lists, or are seen in commit logs of software that is
27			tracked (such as the Linux Kernel).
28
29			It is our philosophy that if the Internet knows that there is a
30			vulnerability in something, then we better know about it and the
31			package maintainer needs to know about it and it needs to be fixed as
32			soon as possible. It doesn't make sense to hide issues that everyone
33			knows about already, in fact users have told us that they prefer to
34			know not only when a package they have installed is vulnerable (so
35			they can disable it or firewall it off, or patch it or whatever), but
36			to also know that Debian is working on a fix. Transparancy is what our
37			users expect, and what they deserve. Tracking publically known issues
38			openly (and the occasional unfortunate embargoed issue privately) is
39			good for the project as a whole, especially the public's perception of
40			the project.
41
42	micah	3520	Gentle Introduction
43	micah	2985	--------------------
44
45			This following will give you a basic walk-through of how the files are
46			structured and how we do our work tracking issues. There is much more
47			that can be documented, but it is difficult to get all the issues
48			notated and updated. It is easier to get a basic idea and then
49			extrapolate from there how to do the rest. Ok, thats a bad excuse, so
50			the full information should be filled in.
51
52			The best way to understand is to check out our repository from
53			subversion so you have the files on your computer and can follow along
54			at home. To do this, you need an Alioth account, and then you just
55			need to do the following:
56
57			svn co svn+ssh://svn.debian.org/svn/secure-testing
58
59			This will check out our working repository into a directory called
60			secure-testing. Inside this directory are a number of subdirectories.
61			The data directory is where we do most of our work.
62
63	jmm-guest	2991	If you don't need write access, you can of course check out our files
64			without an Alioth account as well:
65
66			svn co svn://svn.debian.org/svn/secure-testing
67
68	micah	2985	Automatic Issue Updates
69			-----------------------
70			Twice a day a cronjob runs that pulls down the latest full CVE lists
71			from Mitre, this automatically gets checked into data/CVE/list. We get
72			notified via either email
73			(http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits)
74			of every SVN commit, by RSS feed
75			(http://svn.debian.org/wsvn/secure-testing/?op=rss&rev=0&sc=0&isdir=1)
76			or via the CIA bot on #debian-security on OFTC. For example, the bot
77			will say in the channel:
78
79			17:14 < CIA-1> joeyh * r2314 /data/CVE/list: automatic CAN database update
80
81			Most of our work is taking the new issues that Mitre releases and
82			processing them so that the tracking data is correct. Read on for how we
83			do this.
84
85			Processing TODO entires
86			-----------------------
87			The Mitre update typically manifests in new CVE entries. So what we do
88			is to update our svn repository and then edit data/CVE/list and look
89			for new TODO entries. These will often be in blocks of 10-50 or so,
90			depending on how many new issues they have assigned. Depending on how
91			you feel you will "claim" a block of say 10 new entries by
92			putting your name in the file at the beginning and the end of the new
93			TODO entries and then commit the repository. This looks like this:
94
95			begin claimed by jmm
96			CVE-2005-4066 (Total Commander 6.53 uses weak encryption to store FTP
97			usernams and ...)
98			TODO: check
99			CVE-2005-4065 (SQL injection vulnerability in the search module in
100			Edgewall Trac ...)
101			TODO: check
102			CVE-2005-4030 (SQL injection vulnerability in Quicksilver Forums
103			before 1.5.1 allows ...)
104			TODO: check
105			end claimed by jmm
106
107			Once these are checked-in, then others will not do work on these TODO
108			issues.
109
110			Issues Not-For-Us (NFU)
111			-----------------------
112			Processing your claimed entires is done by first seeing if the issue
113			is related to any software packaged in Debian, if it isn't a package
114			in Debian and has no ITP then you note that in the file, for example:
115
116			CVE-2005-3018 (Apple Safari allows remote attackers to cause a denial of
117			service ...)
118			NOT-FOR-US: Safari
119
120	jmm-guest	3029	Reserved entries
121			----------------
122			Several security problems have coordinated dates of public disclosure,
123			i.e. a CVE identifier has been assigned to a problem, but it's not
124			public yet. Also, several vendors have a pool of CVE ids they can
125			assign to problems that are detected in their products. Such entries
126			are marked as RESERVED in the tracker:
127	micah	2985
128	jmm-guest	3029	CVE-2005-1432
129			RESERVED
130
131			Rejected entries
132			----------------
133			Sometimes there are CVE assignments that later turn out to be duplicates,
134			mistakes or non-issues. These items are reverted and turned into REJECTED
135			entries:
136
137			CVE-2005-4129
138			REJECTED
139
140	micah	2985	ITP packages
141			------------
142			If it is a package that someone has filed an RFP or ITP for, then that
143			is also noted, so it can be tracked to make sure that the issue is
144			resolved before the package enters the archive:
145
146			CVE-2004-2525 (Cross-site scripting (XSS) vulnerability in compat.php
147			in Serendipity ...)
148			- serendipity <itp> (bug #312413)
149
150
151			Packages in the archive
152			-----------------------
153			If it is a package in Debian you look to see if the package is
154			affected or not (sometimes newer versions that have the fixes have
155			already been uploaded).
156
157			If the version has been fixed already, note the package name and the
158			Debian version that fixes it and assign a severity level to it, for
159			example:
160
161			CVE-2005-2596 (User.php in Gallery, as used in Postnuke, allows users
162			with any Admin ...)
163			- gallery 1.5-2 (medium)
164
165			If it hasn't been fixed, I will determine if there has been a bug filed
166			about the issue, and if not, I will file one and then note it in the
167			list (again with a severity level):
168
169			CVE-2005-3054 (fopen_wrappers.c in PHP 4.4.0, and possibly other
170			versions, does not ...)
171			- php4 <unfixed> (bug #353585; medium)
172			- php5 <unfixed> (bug #353585; medium)
173
174	jmm-guest	3039	Bug numbers can be added as in the example above. They are used to add
175			additional references for the overview page and the Security Bug Tracker
176			and they are parsed by a script that generates user tags "tracked" for the
177			user debian-security@lists.debian.org. This way you can generate a BTS
178			query for all issues in the BTS that are tagged "security" and are not
179			yet added to our tracker:
180			http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security;users=debian-security@lists.debian.org;exclude=tracked
181
182	jmm-guest	3029	If a vulnerability does not affect Debian, e.g. because the vulnerable
183			code is not contained, it is marked as <not-affected>:
184
185			CVE-2004-2628 (Multiple directory traversal vulnerabilities in thttpd 2.07 beta 0.4, ...)
186			- thttpd <not-affected> (Windows-specific vulnerabilities)
187
188			<not-affected> is also used if a vulnerability was fixed before a
189			package was uploaded into the Debian archive.
190
191			Sometimes there are cases, where a vulnerability hasn't been fixed with
192			a code change, but simply by deciding that a package is that broken that
193			it needs to be removed from the archive entirely. This is tracked with
194			the <removed> tag:
195
196			CVE-2005-1435 (Open WebMail (OWM) before 2.51 20050430 allows remote authenticated ...)
197			- openwebmail <removed>
198
199
200	jmm-guest	2991	Severity levels
201			---------------
202			These levels are mostly used to prioritize the order in which security
203			problems are resolved. Anyway, we have a rough overview on how you should
204			assess these levels:
205
206			unimportant: This problem does not affect the Debian binary package, e.g.
207	jmm-guest	3029	a vulnerable source file, which is not built or a vulnerable file
208	jmm-guest	2991	in doc/foo/examples/
209			low : A security problem, which has only mild security implications
210			and one would even be comfortable with if it continues to
211			be present
212			medium : A typical, exploitable security problem.
213			high : A typical, exploitable security problem, which you'll really
214	jmm-guest	3029	like to fix or at least implement a workaround. This could
215	jmm-guest	2991	be because the vulnerable code is very broadly used, because
216			an exploit is in the wild or because the attack vector is
217			very wide.
218
219	micah	2985	NOTE and TODO entries
220			---------------------
221			There are many instances where more work has to be done to determine
222			if something is affected, and you might not be able to do this at the
223			time. These entries can have their TODO line changed to something
224			descriptive so that it is clear what remains to be done. For example:
225
226			CVE-2005-3990 (Directory traversal vulnerability in FastJar 0.93
227			allows remote ...)
228			TODO: check, whether fastjar from the gcc source packages is affected
229
230			It is also useful to add information to issues as you find it, so that
231			when others go to look at an issue and want to know why you marked it
232			as you did, or need a reference, it will be there. The more
233			information left, the better. For example, the following entry lets
234			you know that CVE-2005-3258 doesn't affect the squid that we have
235			because the issue was introduced in a patch that was never applied to
236			the Debian package:
237
238			CVE-2005-3258 (The rfc1738_do_escape function in ftp.c for Squid 2.5
239			STABLE11 and ...)
240			- squid <not-affected> (bug #334882; medium)
241			NOTE: Bug was introduced in a patch to squid-2.5.STABLE10,
242			NOTE: this patch was never applied to the Debian package.
243
244	jmm-guest	3027	Distribution tags
245			-----------------
246			Our data is primarily targeted at sid, as we track the version that
247			a certain issue was fixed in sid. The Security Tracker web site (see
248			below) derives information about the applicability of a vulnerability
249			to stable and oldstable from the list of DSAs issued by the security
250			team and the fact that a source package is part of a release.
251			Distribution tags can be used to denote information about a vulnerability
252			for the version of a package in a specific release. An example:
253	micah	2985
254	jmm-guest	3027	CVE-2005-3974 (Drupal 4.5.0 through 4.5.5 and 4.6.0 through 4.6.3, when running on ...)
255			- drupal 4.5.6-1 (low)
256			[sarge] - drupal <not-affected> (Only vulnerable if running PHP 5)
257
258			Drupal has been fixed since 4.5.6, however Drupal from Sarge still isn't
259			vulnerable as the vulnerability is only effective when run under PHP 5,
260			which isn't part of Sarge.
261
262	micah	2985	Generated Reports
263			-----------------
264			All of this tracking information gets automatically parsed and
265			compared against madison to determine what has been fixed and what is
266			still waiting, this results in this page:
267
268			http://spohr.debian.org/~joeyh/testing-security.html
269
270			This page tells us a number of things, for example:
271
272			abiword 2.2.10-1 needed, have 2.2.7-3 for CAN-2005-2964
273
274			This tells us that we know that this fix has been applied in debian
275			package version 2.2.10-1, but testing only has 2.2.7-3. It has links to
276			the reason why this hasn't entered testing yet, as well as the CAN
277			reference at Mitre (given different background colors according to the
278			severity). The ones with bugs have links directly to the bugs that have
279			been filed. Additionally cross-references for DSAs are generated.
280
281			At the bottom is a legend detailing the severity levels, the number of
282			unfixed holes currently in testing, the number of holes that have been
283			fixed in unstable that haven't migrated to testing, and the number of
284			TODO items that we have to process still.
285
286	jmm-guest	3030
287			The DSA list
288			------------
289			We maintain a list of all DSA advisories issued by the stable security
290			team. This information is used to derive information about the state
291			of security problems for the stable and oldstable distribution. An
292			entry for a DSA looks like this:
293
294			[21 Nov 2005] DSA-903-1 unzip - race condition
295			{CVE-2005-2475}
296			[woody] - unzip 5.50-1woody4
297			[sarge] - unzip 5.52-1sarge2
298			NOTE: fixed in testing at time of DSA
299
300	micah	3614	The first line tracks the date, when a DSA was issued, the DSA
301			identifier, the affected source package and the type of vulnerability.
302			The second line performs a cross-reference to the entry in CVE/list
303			that maintains the state of the vulnerability in sid. Every entry that
304			is added like this to DSA/list is parsed by a script and automatically
305			added to CVE/list. The next lines contain the fixes for stable and
306			optionally oldstable, addressed with distribution tags. You may add
307			NOTE: entries freely, we use a NOTE entry for statistical purposes
308			that tracks, when a fix has reached testing relative to the time when
309			it hit stable.
310	jmm-guest	3030
311	micah	3615	There is no need to add anything to CVE/list for a DSA, the DSA
312			cross-reference will be added automatically by the cron job. However,
313			you do need to add [sarge] or [woody] entries to CVE/list when there
314	micah	3614	is a 'no-dsa' or 'not-affected' condition.
315
316	fw	3107	The bin/dsa2list script can be used to generate a template for a new
317			DSA entry once the official DSA is published on the web. You should
318			not blindly trust the script output and double-check it, though.
319
320	jmm-guest	3032	The security bug tracker
321			------------------------
322			There is a more detailed tracker that provides a lot more views into this
323			information, its here:
324	micah	2985	http://idssi.enyo.de/tracker/
325
326	jmm-guest	3032	It incorporates package lists and parses distribution lists and can
327			thus be used to
328			- Present the security history of a package
329			- Provide overviews of vulnerable packages in stable, testing, sid and
330	jmm-guest	3085	oldstable (it still has some false positives, wrt packages in
331	jmm-guest	3032	stable that are present in stable, but not vulnerable, but these
332	stef-guest	3102	will be ironed out soon). The oldstable data is likely inaccurate.
333	jmm-guest	3032	- Generate a list of packages that are subject to security problems, but
334			stuck in testing migration due to problems with the dependency chain
335			and thus candidates for a DTSA
336			- Generate a list of TODO issues that need to be adressed
337			- Generate a list of packages that will enter Debian soon and need to
338			be checked for security problems
339			- Generate a list of provisional IDs that need to be turned into proper
340			CVE entries
341			- Show some potential problems in the data pool (e.g. misspelled package
342			names not found in the packages list, or potentially missing epochs)
343	micah	2985
344	jmm-guest	3032	For every security problem it displays
345			- The CVE information
346			- A severity assessment by NVD
347			- Cross references to DTSAs, DSAs and bugs in the BTS
348			- The status of a security problem in stable, oldstable, testing and sid
349			- Additional notes from our tracker
350
351	micah	2985	Following up on security issues
352			-------------------------------
353			By simply loading this page and doing a little gardening of the
354			different issues many things can be done. One thing is that you can
355			read all the bug reports of each issue and see if new information has
356			been added to the end that might provide updated or changed
357			information (such as if an issue has been closed, or a version of the
358			package has been uploaded that contains the fix). It is also useful to
359			follow-up on the issues to prod the maintainer to deal with the issue,
360			which they may have forgotten about.
361
362
363			IRC Channel
364			-----------
365			We hang-out on #debian-security on OFTC, stop by the IRC channel if
366			you'd like, also we can add you to the alioth project so you have svn
367			write permission and you can test drive it on the testing issues for
368			however long you like to get an idea or feel comfortable (and hey it
369			helps!)
370
371
372			TODO:
373			document DTSAs
374			document tsck
375	jmm-guest	3032	document CVE-XXXX
376			document tracked tag