Secure testing commits - Jan 2011 - r15917 - / data doc doc/historic

Author: gilbert-guest
Date: 2011-01-18 02:17:49 +0000 (Tue, 18 Jan 2011)
New Revision: 15917

Added:
   doc/historic/
   doc/historic/README
   doc/historic/TODO
   doc/historic/announce
   doc/historic/announce.2
   doc/historic/announce.3
   doc/historic/bits_2007_10_x
   doc/historic/bits_2008_06_x
   doc/historic/lenny_release
   doc/historic/mopb.txt
   doc/historic/mops.txt
   doc/historic/move_to_l.d.o
   doc/historic/testing-security
   doc/historic/tmp.txt
Removed:
   TODO
   data/README
   data/mopb.txt
   data/mops.txt
   doc/announce
   doc/announce.2
   doc/announce.3
   doc/bits_2007_10_x
   doc/bits_2008_06_x
   doc/lenny_release
   doc/move_to_l.d.o
   doc/testing-security
   tmp.txt
Log:
create a historic document dir and move a bunch of outdated stuff there

Deleted: TODO
==================================================================--- TODO
2011-01-18 02:17:42 UTC (rev 15916)
+++ TODO	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,50 +0,0 @@
-* Set up for DTSAs
-
-  - Auto moderation of developer signed mails to -announce.
-
-  - sndadvisory should remove TODO lines from the list file since the
-    advisory is complete
-
-  - merge sndadvisory into dtsa script?
-
-  - web DTSA pages should be built on the fly using the metadata in DTSA/
-    so we don''t have to update things in two places when making a
change,
-    and so releasing a DTSA does not involve copying html files around
-
-  - The dtsa script should have support for updating the list file
-    when running it on an advisory that it''s already been run on
before.
-    This would facilitate issuing asvisories, which often takes a few runs
-    before the final one is sent. Alternatively, get rid of the DTSA/list
-    file (do we need it for anything really?)
-
-* Merge stuff into security.debian.org. Long term, but we need to keep in
-  mind that the current archive setup is just to get bootstrapped.
-
-* Web overview
-  - checklist setup for unstable needs to be fixed to ignore Hurd
-
-* Florian''s overview should be moved to secure-testing.debian.net, but
-  Florian wants to resolve some issues before.
-
-* Write the script that digs through the security bugs
-
-* Write the script that handles the transfer between secure-testing and testing
-  wrt incomplete archs (aba)
-
-* Improve the developer''s reference wrt security bugs (micah)
-
-* Document that finalized syntax
-
-* Review open security bugs and tag the wrt versioned bug tracking
-
-* Create a repo of security patches
-
-* Retroactive updating of the list for not-affected and others
-
-* Document all our stuff and work
-
-* Implement the HELP tag and add it to some outstanding issues
-
-* Link source package specific overview into the PTS
-
-

Deleted: data/README
==================================================================---
data/README	2011-01-18 02:17:42 UTC (rev 15916)
+++ data/README	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,55 +0,0 @@
-The checklist program can be run on a system with madison available to
-check vulnerability info from the list files against what packages are in
-testing. Also the updatelist is used by the Makefile to update the lists
-with new info from Mitre. So the various list files need a common, machine
-parsable format. That format is:
-
-begin claimed by foo
-
-[date] id description
-	{id id id}
-	UPCASE: text
-	- package [version] (note; note; note)
-
-end claimed by foo
-
-
-Without writing a format grammar, because this is really rather ad-hoc and
-probably will be replaced with something better:
-
-[date]
-	The date of the advisory in the form dd Mmm YYYY (01 Nov 2004).
-	Optional, only given for DSAs at the moment.
-id
-	DSA-nnn-n, CVE-YYY-nnnn, etc
-description
-	Pretty much freeform description of the problem. Short and optional.
-	By convention, if it''s taken from upstream data source
-	automatically, it will be in parens.  If you want to use a different
-	description, put it in square brackets instead.
-{id id id}
-	This is used to link to other ids that describe the same hole.
-	Generally used to link DSAs to CVEs and back.
-UPCASE
-	Any word in upper case, typically NOTE, HELP, TODO, RESERVED,
-	REJECTED, NOT-FOR-US.
-	May be repeated for each entry.
-- package [version] (note; notes; note)
-	Indicates that the problem is fixed in the given version of the
-	package. May repeat for other packages. If the problem is unfixed,
-	use "<unfixed>" as the version. If the problem
doesn''t affect Debian,
-	use "<not-affected>" as the version. If the problem only
affects
-	shipped releases, for which the stable security team provides
-	security support and the affected package has meanwhile been removed
-	from the archive use "<removed>" as the version.  If the
problem
-	affects a particular release, prepend "[release]" before the
-	"- package" to reflect as much.
-
-	The notes can be freeform, but some are understood by the tools,
-	including "bug #nnnnn", "bug filed", and "high",
-        "medium", "low", "unimportant" and
"unknown" urgencies.
-
-begin claimed by foo
-end claimed by foo
-	Marks a set of items that are being checked by someone.
-	Used to avoid duplicate work.

Deleted: data/mopb.txt
==================================================================---
data/mopb.txt	2011-01-18 02:17:42 UTC (rev 15916)
+++ data/mopb.txt	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,237 +0,0 @@
-Issues affecting PHP 4 and PHP 5:
-
-41  PHP 5 sqlite_udf_decode_binary() Buffer Overflow Vulnerability
-#TODO(medium) -> for PHP5, php4 uses a seperate php4-sqlite package.
-[MOPB-41-php5.diff]
-
-34  PHP mail() Header Injection Through Subject and To Parameters
-#TODO(medium) -> needs to be fixed, CVE-2007-1718 (php4 & php5, header
-injection possible via some MTAs when set to process the headers for
-recipients), Sarge''s php4 not affected
-[MOPB-34-php5.diff]
-
-30  PHP _SESSION unset() Vulnerability
-#TODO(low) -> hard to trigger remotely, CVE-2007-1700. (php4 & php5,
code execution)
-[MOPB-30-php5.diff]
-
-26  PHP mb_parse_str() register_globals Activation Vulnerability
-#TODO(medium) -> functionally enables register_globals for any future
requests, CVE-2007-1583 (php4 & php5, enables stealth register_globals for
life of process)
-
-22  PHP session_regenerate_id() Double Free Vulnerability
-#TODO(medium) -> locally exploitable to gain access to process memory, hard
to do remotely, CVE-2007-1521 (php4 & php5, code execution)
-[MOPB-22-php5.diff]
-
-10  PHP php_binary Session Deserialization Information Leak  Vulnerability
-#TODO(low) -> Can only leak 127 bytes of data, CVE-2007-1380 (php4 &
php5, heap leak)
-Check, to which extent this was covered by our backports of 5.2.1 patches
-[MOPB-10-php5.diff]
-
-
-
-Issues affecting PHP 4 only:
-
-35  PHP 4 zip_entry_read() Integer Overflow Vulnerability
-#TODO(medium) -> needs to be fixed, CVE-2007-1777 (php4, remote code
execution)
-[MOPB-35-php4.diff]
-
-32  PHP 4.4.5/4.4.6 session_decode() Double Free Vulnerability (U) 
-TODO(medium) -> needs to be fixed in php/etch and php/sarge (remote code
execution)
-[MOPB-32-php4.diff]
-
-04  PHP 4 unserialize() ZVAL Reference Counter Overflow
-TODO (php4 only, gain execute control)
-[MOPB-04-php4.diff]
-
-
-
-Issues affecting PHP 5 only:
-
-45  PHP ext/filter Email Validation Vulnerability
-TODO(low) -> possible email header injections when coupled with other
problems (php5 5.2.0, 5.2.1)
-[MOPB-45-php5.diff]
-
-44  PHP 5.2.0 Memory Manager Signed Comparision Vulnerability
-#TODO(medium) -> remotely exploitable via SOAP interfaces, CVE-2007-1889
(php5 5.2.0 only)
-
-42  PHP 5 php_stream_filter_create() Off By One Vulnerablity
-#TODO(medium) -> needs to be fixed, CVE-2007-1824 (php5, remote code
execution, though haven''t reproduced it)
-[MOPB-42-php5.diff]
-
-23  PHP 5 Rejected Session Identifier Double Free Vulnerability
-#TODO(medium) -> locally exploitable to gain access to process memory, hard
to do remotely, CVE-2007-1522. (php5 5.2.0+, code execution)
-
-19 PHP ext/filter Space Trimming Buffer Underflow Vulnerability
-#TODO(medium) -> for PHP5. CVE-2007-1453 (php5 5.2.0 only, code execution on
big endian)
-
-18  PHP ext/filter HTML Tag Stripping Bypass Vulnerability
-#TODO(medium) -> for PHP5. CVE-2007-1453 (php5 5.2.0 only, can avoid
filters)
-
-17  PHP ext/filter FDF Post Bypass Vulnerability
-#TODO(low) -> ...or possibly "broken as designed". CVE-2007-1452,
(php5 5.2.0 only, can avoid filters)
-
-16  PHP zip:// URL Wrapper Buffer Overflow Vulnerability
-#TODO(medium) -> possible remote data can result in code execution in 5.2.0
which uses the zip handler, CVE-2007-1399. (php5 5.2.0 only, code execution)
-
-14  PHP substr_compare() Information Leak Vulnerability
-#TODO(low) -> corner-case where length+offset > INT_MAX, CVE-2007-1375
(php5, heap leak)
-[MOPB-14-php5.diff]
-
-
-
-
-
-Done or resolved:
-
-
-43  PHP msg_receive() Memory Allocation Integer Overflow Vulnerabilty
-#N/A -> Only triggerable by malicious script, CVE-2007-1890 (php4 &
php5, local code execution, possibly FreeBSD only)
-
-40  PHP imap_mail_compose() Boundary Stack Buffer Overflow Vulnerability
-#Fixed in DSA-1264 and the respective PHP4/PHP5 packages, dupe
CVE-2007-0906/CVE-2007-1825
-
-39  PHP str_replace() Memory Allocation Integer Overflow Vulnerability
-#Fixed in DSA-1264 and the respective PHP4/PHP5 packages, dupe
CVE-2007-0906/CVE-2007-1885
-
-38  PHP printf() Family 64 Bit Casting Vulnerabilities
-#Fixed in DSA-1264 and the respective PHP4/PHP5 packages, dupe
CVE-2007-0909/CVE-2007-1884
-
-37  PHP iptcembed() Interruption Information Leak Vulnerability
-#N/A -> Only triggerable by malicious script, CVE-2007-1883 (php4 &
php5, local code execution)
-
-36  PHP session.save_path open_basedir Bypass Vulnerability
-#N/A -> open_basedir bypasses not supported, CVE-2007-1461
-
-33  PHP mail() Message ASCIIZ Byte Truncation
-#N/A -> This is a bug, but not security-relevant, CVE-2007-1717 (php4 &
php5)
-
-31  PHP _SESSION Deserialization Overwrite Vulnerability
-#N/A -> register_globals not supported, already fixed in DSA-1264, dupe
CVE-2007-0910/CVE-2007-1701 (php4 & php5, very hard to trigger remotely,
code execution)
-
-29  PHP 5.2.1 unserialize() Information Leak Vulnerability
-#N/A -> Only affects PHP 5.2.1, CVE-2007-1649 (heap leak via broken
"S" unserializer, which should maybe be removed from 5.2.1, since it
is only for future compatibility and is totally broken?)
-[MOPB-29-php5.diff]
-
-28  PHP hash_update_file() Already Freed Resource Access Vulnerability
-#N/A -> Only triggerable by malicious script, CVE-2007-1581 (php5, local
malicious stream handler leads to code execution)
-
-27  PHP ext/gd Already Freed Resource Access Vulnerability
-#N/A -> Only triggerable by malicious script, CVE-2007-1582 (php4 &
php5, local malicious error handler leads to code execution)
-
-25  PHP header() Space Trimming Buffer Underflow Vulnerability
-#Fixed in Etch as part of the 5.2.1 backport, dupe CVE-2007-0907/CVE-2007-1584
-
-24  PHP array_user_key_compare() Double DTOR Vulnerability
-#N/A -> Only triggerable by malicious script, CVE-2007-1484 (php4 &
php5, code execution)
-[MOPB-24-php5.diff]
-
-21  PHP compress.bzip2:// URL Wrapper safemode and open_basedir Bypass
Vulnerability
-#N/A -> Safemode and open_basedir bypasses not supported, CVE-2007-1461
-
-20  PHP zip:// URL Wrapper safemode and open_basedir Bypass Vulnerability
-#N/A -> Safemode and open_basedir bypasses not supported, CVE-2007-1460
-
-15  PHP shmop Functions Resource Verification Vulnerability
-#N/A -> Only triggerable by malicious script, could be used to read/write
arbitrary memory, CVE-2007-1376 (php4 & php5, arbitrary memory leakage)
-[MOPB-15-php5.diff]
-
-13  PHP 4 Ovrimos Extension Multiple Vulnerabilities
-#N/A -> Ovrimos support not provided in any debian php packages,
CVE-2007-1379, CVE-2007-1378
-
-12  mod_security POST Rules Bypass Vulnerability
-#N/A -> applies to modsecurity, not packaged for sarge/etch/(sid?),
CVE-2007-1359.
-
-11  PHP WDDX Session Deserialization Information Leak Vulnerability
-#Fixed in DSA-1264. CVE-2007-0908 (php4 & php5, controllable stack leak)
-
-09  PHP wddx_deserialize() String Append Buffer Overflow Vulnerability
-#N/A -> Only applies to a development version in CVS, not a shipped release,
CVE-2007-1381.
-
-08  PHP 4 phpinfo() XSS Vulnerability (Deja-vu)
-N/A -> phpinfo() is a debug function, not be exposed to applications (php4
4.4.3 through 4.4.6 only, phpinfo XSS)
-
-07  Zend Platform ini_modifier Local Root Vulnerability (B)
-N/A -> Only affects the Zend platform
-
-06  Zend Platform Insecure File Permission Local Root Vulnerability
-N/A -> Only affects the Zend platform
-
-05  PHP unserialize() 64 bit Array Creation Denial of Service  Vulnerability
-#Fixed in DSA-1264. CVE-2007-0988 (php4 & php5, limited-time 100% CPU DoS)
-
-03  PHP Variable Destructor Deep Recursion Stack Overflow
-#N/A -> Applications need to impose sanity checks for maximum recursion,
CVE-2007-1285 (php4 & php5, crash only)
-
-02  PHP Executor Deep Recursion Stack Overflow
-#N/A -> Applications need to impose sanity checks for maximum recursion,
CVE-2006-1549 (php4 & php5, crash only)
-
-01  PHP 4 Userland ZVAL Reference Counter Overflow Vulnerability
-#N/A -> Only triggerable by malicious script, CVE-2007-1383 (php4 only, gain
execute control)
-
-
-
-
-(Comments starting with # indicate that information has been fed to the
tracker)
-(Comments starting with TOFIX indicate that a patch has been created or
extracted)
-
-
-# php4 checklist
-
-   Sarge Etch
-41   a    a <- seperate source package php4-sqlite
-35   T    T
-34   /    t
-32   T    T 
-30   /    /
-26   a    a
-22   t    t 
-10   T    T <- seemed already fixed but this completes the patch
-04   T    T
-
-? = more info
-x = fix needed
-* = extracted
-a = patch generated and commited to SVN
-t = didn''t seem affected, but patch makes sense
-T = code tested
-/ = not affected
-
-# PHP5 checklist....
-MOPB   Etch, Unstable  Dapper, Edgy, Feisty, Gutsy       PATCH
-10      p     p[3]      T       T     T       -            *
-14      X     T         T       T     T       -            *
-15      i     T         T       T     -       -            *
-16      p     p         -       -     -       -
-17      -     -         -       -     -       -
-18      X     T         -       -     -       -
-19      X     T         -       -     -       -
-22      X     T         T       T     T       -            *
-23      X     T[5]      X       X     X       -            ?
-24      i     i         T       T     T       X            *
-26      X     T         T       T     T       -            *
-29      -     -         -       -     T       -            *
-30      -     a[4]      T       T     -       -            *
-34      X     a         T       T     T       -            *
-41      X     T         T       T     T       -            ![1]
-42      X     a         T       T     -       -            *
-44      X     a         -       -     -       -
-45      X     T         -       -     T       -            ![2]
-
-* = patch extracted from upstream
-? = no upstream patch found
-! = patch created
-
-X = fixed desired
-a = patch applied
-p = previously fixed
-T = code tested
-- = fix n/a
-i = fix skipped
-
-[1] but the fix in php5 is not right, the call (not the SQLite API) needs
-    to be changed.  For references, here is the upstream "fix":
-   
http://cvs.php.net/viewvc.cgi/php-src/ext/sqlite/libsqlite/src/encode.c?r1=1.5.4.1&r2=1.5.4.1.2.1&pathrev=PHP_5_2
-[2] this needs a CVE assigned
-[3] previously fixed, but the patch adds another check we should have too.
-[4] could not reproduce this problem
-[5] the first hunk of the patch for mopb 22 fixes this.
-

Deleted: data/mops.txt
==================================================================---
data/mops.txt	2011-01-18 02:17:42 UTC (rev 15916)
+++ data/mops.txt	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,64 +0,0 @@
-Month of PHP security May 2010 status file
-
-001: CVE-2007-1581; Only triggerable by malicious script
-002: External app not in Debian: Campsite
-003: CVE-2010-1866; Should be fixed for Squeeze, doesn''t affect Lenny
(5.3 only)
-004: External app not in Debian: ClanSphere
-005: External app not in Debian: ClanSphere
-006: CVE-2010-1864; Only triggerable by malicious script
-007: External app not in Debian: ClanTiger
-008: CVE-2010-1862; Only triggerable by malicious script
-009: CVE-2010-1861; Only triggerable by malicious script
-010: CVE-2010-1860; Only triggerable by malicious script
-011: External app not in Debian: DeluxeBB
-012: CVE-2010-1868; Only triggerable by malicious script
-013: CVE-2010-1868; Only triggerable by malicious script
-014: CVE-2010-1914; Only triggerable by malicious script
-015: CVE-2010-1914; Only triggerable by malicious script
-016: CVE-2010-1914; Only triggerable by malicious script
-017: CVE-2010-1915; Only triggerable by malicious script
-018: External app not in Debian: EFront
-019: CVE-2010-1916; Serendipity, doesn''t affect Lenny (1.4 onwards),
pinged Thijs
-020: CVE-2010-1916; External app; xinha, Just an ITP: #479708, there are
embedders
-021: CVE-2010-1917; PHP fnmatch() Stack Exhaustion Vulnerability
-022: CVE-2010-2093; Only triggerable by malicious script
-023: no CVE yet; Cacti, pinged Sean Finney
-024: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
-025: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
-026: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
-027: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
-028: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
-029: External app not in Debian: CMSQLITE
-030: External app not in Debian: CMSQLITE
-031: External app not in Debian: e107
-032: CVE-2010-2097; Only triggerable by malicious script
-033: CVE-2010-2097; Only triggerable by malicious script
-034: CVE-2010-2097; Only triggerable by malicious script
-035: External app not in Debian: e107
-036: CVE-2010-2100; Only triggerable by malicious script
-037: CVE-2010-2100; Only triggerable by malicious script
-038: CVE-2010-2100; Only triggerable by malicious script
-039: CVE-2010-2100; Only triggerable by malicious script
-040: CVE-2010-2100; Only triggerable by malicious script
-041: CVE-2010-2101; Only triggerable by malicious script
-042: CVE-2010-2101; Only triggerable by malicious script
-043: CVE-2010-2101; Only triggerable by malicious script
-044: CVE-2010-2101; Only triggerable by malicious script
-045: CVE-2010-2101; Only triggerable by malicious script
-046: CVE-2010-2101; Only triggerable by malicious script
-047: CVE-2010-2190; Only triggerable by malicious script
-048: CVE-2010-2190; Only triggerable by malicious script
-049: CVE-2010-2191; Only triggerable by malicious script
-050: CVE-2010-2191; Only triggerable by malicious script
-051: CVE-2010-2191; Only triggerable by malicious script
-052: CVE-2010-2191; Only triggerable by malicious script
-053: CVE-2010-2191; Only triggerable by malicious script
-054: CVE-2010-2191; Only triggerable by malicious script
-055: CVE-2010-2191; Only triggerable by malicious script
-056: CVE-2010-3062; Does not affect Lenny; unimportant, mysqlnd not used in
squeeze/sid
-057: CVE-2010-3062; Does not affect Lenny; unimportant, mysqlnd not used in
squeeze/sid
-058: CVE-2010-3063; Does not affect Lenny; unimportant, mysqlnd not used in
squeeze/sid
-059: CVE-2010-3064; Does not affect Lenny; unimportant, mysqlnd not used in
squeeze/sid
-060: CVE-2010-3065; Should be fixed in Lenny and unstable; low importance
-
-

Deleted: doc/announce
==================================================================---
doc/announce	2011-01-18 02:17:42 UTC (rev 15916)
+++ doc/announce	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,133 +0,0 @@
-Subject: forming a security team for testing
-
-I''ve been talking to people about the idea of forming a security team
for
-the testing distribution for several months, and there seems to be enough
-interest in improving testing''s security to make such a team a
reality.
-Most of the people in the CC list have indicated interest in the existence
-of a testing security team; we''re interested in testing''s
security for
-diverse reasons including: use of testing at work, shipping products based
-on testing, hoping to base derived Deban distributions on testing rather
-than stable, wanting testing to be a viable choice for Debian users, and
-so on.
-
-The team will consist of Debian developers and possibly others. Unless a
-member of the Debian security team joins the Debian testing security team,
-none of us will have any privileged information about future security
-announcements. Anyone with interest and experience with security issues is
-welcome to join the team.
-
-To talk about how I think this team would work on testing''s security,
I
-need to talk about two distinct stages, before the sarge release, and
-after.
-
-Right now we''re at a point in the sarge release cycle where most of
the
-focus of a testing security team needs to be on identifying and fixing
-sarge''s security problems and getting it ready for release. This means
-checking to make sure that security problems that have already been fixed
-in unstable and stable do not continue to affect testing, as well as
-dealing with new holes. I don''t think Debian has really invested much
-effort into this in past releases, but if we want sarge to be a secure
-release from the beginning, it''s important to do it.
-
-If we do that work now, then after sarge is released, we will only need to
-worry about keeping track of new security holes and releasing security
-advisories.
-
-Work before sarge''s release:
----------------------------
-
-Some work on checking sarge for old security issues has already been done.
-With help from some of the people in the CC list, I coordinated a scan of
-every DSA since woody''s release and we checked all 450 DSAs to see if
fixes
-for those security holes had reached testing. Suprisingly, we found some
-security holes that had not gotten fixed in testing in a year or more,
-though those were the exceptions.
-
-I''ve continued to do this checking as each new DSA is released, as
well as
-filing bugs, working with the security team and Release Managers, and doing
-a few NMUs to get the fixes in. The current list of unfixed DSAs sarge is:
-
-	joeyh at newraff:~/sarge-checks>./checklist.pl DSA/list 
-	kpdf (unfixed; bug #278173) for DSA-573-1
-	gpdf 2.8.0-1 needed, have 2.8.0-0.1 for DSA-573-1
-	libpng3 1.2.5.0-9 needed, have 1.2.5.0-8 for DSA-571-1
-	kdelibs 4:3.2.3-3.sarge.1 needed, have 4:3.2.3-2 for DSA-539
-
-But checking DSAs is not a complete check of known security issues that
-might still be lurking in sarge. To do a really complete scan means looking
-through old non-DSA advisories as far back as is reasonable or doable. I
-think doing this scan and the following up on it to fix things would be a
-good first step for the team, and a way to begin figuring out how the team
-will work together.
-
-Mitre has a fairly comprehensive list of security problems in their list of
-CAN numbers[1]. There have been about 1000 CANs allocated this year, some
-of them are not released yet, some were covered by the DSAs and I''ve
-checked a few hundred, so there are about 400 left. I think 4 or 5 people
-could check these in a reasonable time period, and maybe do 2003 as well.
-So if you''re interested in checking some of the CANs to see if they
are
-fixed in sarge, here''s what to do:
-
- - Sign up for an alioth account if you don''t have one.
- - Send me your userid to be added to the secure-testing project on alioth.
- - svn co svn+ssh://svn.debian.org/svn/secure-testing/sarge-checks
- - Edit the CAN/list file and claim a range of CANs to check. Note that
-   CANs that have already been checked as part of the DSA checks are so
-   marked. Commit the file.
- - Go through your claimed CANs and check changelogs, advisories, do
-   testing, whatever is needed to satisfy yourself whether sarge is
-   vulnerable or not, and record your findings in the CANs file.
- - If it''s also not fixed in sid, then be sure to file a RC bug; if
it''s
-   fixed in sid but not in sarge, be sure to record it as a critical issue
-   on the Release Managers'' sarge issue tracker here:
-   http://www.wolffelaar.nl/~sarge/
-   Do other followup as appropriate to get the fix into sarge.
-
-Along with looking for old unfixed holes in sarge and working on getting
-them fixed, we should also keep up-to-date with tracking new holes as
-they''re announced.
-
-Work after sarge''s release:
---------------------------
-
-By the time sarge releases, I hope to already have a team that has worked
-together on getting sarge secure, and we''ll have a testing
distribution
-with no old security holes in it. This would be a great time to start
-regular security updates for testing. I''ve been considering some
acheivable
-goals for the testing security team, and come up with this list:
-
- - Provide timely security updates for testing, with fixes being made
-   available no more than four days after a DSA is released.
- - Work with maintainers to include security fixes from unstable
-   that do not have DSAs.
- - Maintain a public database and statistics about the current state of
-   security in testing.
-
-Exactly how we would handle doing security updates for testing will have to
-be decided by the team. We will probably want to release gpg signed DTSA
-(Debian Testing Security Advisories) to a mailing list and web site. It
-seems likely that we could use the testing-proposed-updates queue to build
-updates, if it gets set up for all arches and continues to work after the
-sarge release. For tracking issues, we may need to come up with our own
-system, or we may be able to use the BTS, it if gets the promised version
-tracking support added to it. We might want to set up our own security
-repository separate from testing, or not.
-
-I think it''s important that the team not rely on others in Debian to
do the
-work for infrastructure we need; if it''s available then great, but if
not
-we should be prepared to work around it ourselves.
-
-While it''s again up to the eventual team to decide for sure, I suggest
that
-we build security updates against the packages in testing. I also suggest
-that unlike security updates to package in stable, we should most often not
-backport fixes to the versions of packages in testing. More often we will
-simply take the fixed package from unstable, recompile it if necessary, and
-qualify it for the testing distribution. This may involve upgrading to new
-upstream releases, and so there''s a chance our updates will introduce
new
-bugs. Still, that''s not as bad as unfixed security holes, and for a
small
-team with limited manpower, this is a useful shortcut. We can make sure
-that our users realise that using our security updates can expose them to
-upgrade bugs.
-
-[1] http://cve.mitre.org/cve/candidates/downloads/full-can.html
-

Deleted: doc/announce.2
==================================================================---
doc/announce.2	2011-01-18 02:17:42 UTC (rev 15916)
+++ doc/announce.2	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,127 +0,0 @@
-Subject: announcing the beginning of security support for testing
-
----------------------------------------------------------------------------
-Debian Testing Security Team                            September 9th, 2005
-secure-testing-team at lists.alioth.debian.org
-http://testing-security.debian.net/
----------------------------------------------------------------------------
-
-Security support for testing
-
-The Debian testing security team is pleased to announce the beginning of
-full security support for Debian''s testing distribution. We have spent
the
-past year building the team, tracking and fixing security holes, and
-creating our infrastructure, and now the final pieces are in place, and 
-we are able to offer security updates and advisories for testing.
-
-We invite Debian users who are currently running testing, or who would like
-to switch to testing, to subscribe to the secure-testing-announce mailing 
-list, which will be used to announce security updates.
-<http://lists.alioth.debian.org/mailman/listinfo/secure-testing-announce>
-
-We also invite you to add the following lines to your apt sources.list file,
-and run "apt-get update && apt-get upgrade" to make the
security updates
-available.
-
-deb http://secure-testing.debian.net/debian-secure-testing
etch/security-updates main contrib non-free
-deb-src http://secure-testing.debian.net/debian-secure-testing
etch/security-updates main contrib non-free
-
-Alternatively, replace "secure-testing.debian.net" in the above lines
with
-a mirror near you:
-
-	ftp.de.debian.org         (located in Germany)
-	ftp.nl.debian.org         (located in the Netherlands)
-	the.earth.li              (located in UK)
-	ftp2.jp.debian.org        (located in Japan)
-	farbror.acc.umu.se        (located in Sweden)
-
-Some initial advisories have already been posted to the list and are already
-available in the repository. These include:
-
-[DTSA-1-1] New kismet packages fix remote code execution
-[DTSA-2-1] New centericq packages fix multiple vulnerabilities
-[DTSA-3-1] New clamav packages fix denial of service and privilege escalation
-[DTSA-4-1] New ekg packages fix multiple vulnerabilities
-[DTSA-5-1] New gaim packages fix multiple remote vulnerabilities
-[DTSA-6-1] New cgiwrap packages fix multiple vulnerabilities
-[DTSA-7-1] New mozilla packages fix frame injection spoofing
-[DTSA-8-1] New mozilla-firefox packages fix several vulnerabilities
-[DTSA-9-1] New bluez-utils packages fix bad device name escaping
-[DTSA-10-1] New pcre3 packages fix buffer overflow
-[DTSA-11-1] New maildrop packages fix local privilege escalation
-[DTSA-12-1] New vim packages fix modeline exploits
-[DTSA-13-1] New evolution packages fix format string vulnerabilities
-
-Note that while all of Debian''s architectures are supported, we may
release
-an advisory before fixed packages have built for all supported
-architectures. If so, the missing builds will become available as they
-complete.
-
-We are not currently issuing advisories for security fixes that reach
-testing through normal propagation from unstable, but only for security
-fixes that are made available through our repository. So users of testing
-should continue to upgrade their systems on a regular basis to get such
-security fixes. We might provide information about security issues that
-have been fixed through regular testing propagation in the future, though.
-
-Note that this announcement does not mean that testing is suitable for
-production use. Several security issues are present in unstable, and an
-even larger number are present in testing. Our beginning of security
-support only means that we are now able to begin making security fixes
-available for testing nearly as quickly as for unstable. The testing
-security team''s website has information about what security holes are
still
-open, and users should use this information to make their own decisions
-about whether testing is secure enough for them.
-
-Finally, we are still in the process of working out how best to serve users
-of testing and keep your systems secure, and we welcome comments and
-feedback about ways to do better. You can reach the testing security team
-at secure-testing-team at lists.alioth.debian.org.
-
-If you want to become a mirror, please see
-http://testing-security.debian.net/mirroring.html
-
-Debian developers who would like to upload fixes for security holes in
-testing to the repository can do so, following the instructions on our web
-site. 
-
-For more information about the testing security team, see our web site.
-<http://testing-security.debian.net/>.
-
-----------------------------------------------------------------------------
-
-The archive signing key that is used to sign the apt repository is
-included below and can also be downloaded from
-http://testing-security.debian.net/ziyi-2005-7.asc
-
------BEGIN PGP PUBLIC KEY BLOCK-----
-Version: GnuPG v1.4.1 (GNU/Linux)
-
-mQGiBEMM7wgRBACs/rcYtu++PqBV5t6qTf9FsjJYZV4OUoQmtK849PdHUoVONh/b
-yz0vmP4QPCJXraFYiiiaur8WLcOphwY3DFaz0quozxl3pZfJjN27qDdTTDUKk1Kq
-zFQYTsDaXjSh0nRGW3gFmbyIqTL8sVGOAAz2KbrtLEQE11qYZjzvylEf4wCgv6ss
-HgQ7AcSBjpvm72e9PvSuDhMD/1kV0Snq9ilvCv7QLHBo/JnNgiCwxh5nEnPWHYjo
-SB0I99nuFMAzooAXTQhU3Hx1/sdZ3SMk1hWwZCPI0iNqESH2a3ib0YZt0DycWa3Y
-KxXIJet92u3ApSMVbp6OzzL7REoNCAgg6F/lrl+lVtnHbKiKBMZlKMsp+kQLSXqr
-Ki0pA/wIkkp7mJ7IiVS0fy9gueuiLqJKR6+i092J0RXsQesQX4OTC2DY3IICB22Q
-HfE8WNVZ2iPuWK0ymg6GqAHplp7bfVZMzfMSTMc+hj9WnmEVRRjLH66tsq1XHGEQ
-qg/mbkmeXwUwxAT1WGClcRWJqODmWE7KhkjKwGklYgzBoxwqkLRDc2VjdXJlLXRl
-c3RpbmcgQXJjaGl2ZSBLZXkgMjAwNS03IDxrYXRpZUBzZWN1cmUtdGVzdGluZy5k
-ZWJpYW4ubmV0PohkBBMRAgAkBQJDDO8IAhsDBQkElVcABgsJCAcDAgMVAgMDFgIB
-Ah4BAheAAAoJEJRqpuGHIucecvgAoK3nnF0yEwpNeQASyerh4wxRblZzAJ9h8rEF
-YldbZt/zYA53k2/y2m+s7LkCDQRDDO8gEAgAm1Y/a//sVe6fEANvLc5M5pEsoRkP
-LNKcH1O/og2mID8/gBV99LRfRnjcV8xhF5cWIlb4Es3KvQxmvxo6zGEfsMJWoezq
-H+2agIra78dfb0B1AyHuvwSRMc9sVy+3CuegM8bD3ss+4ta3rNLChpVrE8DxJZum
-ecqkNSQVOkqeAOl2JIQ/xBkLg1hjQA8bXW5AiUu4/XAQAe04w7YNfdsApeCfpKEW
-Atg54CD9uRbfSwnd2uYHYcosmBMhryNrHy27RkyS0BFWaL/1gfBqua7VujcnCm6S
-nbhB4t3vk/AnEsPJixtW/tOC3a3BaPqGsTq848e/PzmWY/8y9mvXwbxq5wADBQgA
-gNtB3u8TCN2Z4wkKrg19LohivQzJCXFfRi2ZydOe9E3SbSi6ggthjvGhHv2lTHEu
-e/4wBOta3a9pUpVdMgRFL1UuJy3nPd1yPC0dOegJj+lMkeMGcdKolJUMdoA+ieZ2
-lwkrT1b5GdFBSRn8hsuRtZi69QtzoHzDR5lg9ynwTJ+mLlO8r83HmdxbXsnmGlxy
-ZWRoqiSIl7mRLHp2tuFw9chgJ1nqwewTmCj85Aj/YsbGmqOJcnp98Jk0GDiP/le4
-rktZAqG2blwVpC2DLLiQSqcYS5jjq/iiGnYEIVG+nPa/29OuoX40zwKqBcy5I8rJ
-ZIq2hzbazsyg2Sd3vhmZuohPBBgRAgAPBQJDDO8gAhsMBQkElVcAAAoJEJRqpuGH
-IuceRqUAn3Q8msRUTsp882QINWyy5fqTehb5AJ9+kz3xq+7ooAwkdgpNOiz7ogxp
-Qg=-=KBNL
------END PGP PUBLIC KEY BLOCK-----

Deleted: doc/announce.3
==================================================================---
doc/announce.3	2011-01-18 02:17:42 UTC (rev 15916)
+++ doc/announce.3	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,46 +0,0 @@
-X-pseudo-subject: For those who care about testing security
-Subject: Testing security archive move
-
----------------------------------------------------------------------------
-Debian Testing Security Team                                 May 12th, 2006
-secure-testing-team at lists.alioth.debian.org
-http://testing-security.debian.net/
----------------------------------------------------------------------------
-
-Testing security archive move
-
-The Debian testing security team is pleased to announce the integration of
-the secure testing archive to http://security.debian.org
-
-We invite Debian users who are currently running testing, or who would like
-to switch to testing, to subscribe to the secure-testing-announce mailing 
-list, which will be used to announce security updates.
-<http://lists.alioth.debian.org/mailman/listinfo/secure-testing-announce>
-
-We also invite you to add the following lines to your apt sources.list file,
-and run "apt-get update && apt-get upgrade" to make the
security updates
-available.
-
-deb http://security.debian.org etch/updates main contrib non-free
-deb-src http://security.debian.org etch/updates main contrib non-free
-
-This replaces the previous http://secure-testing.debian.net/ lines which should
-no longer be used. There will be a transition period where packages are
-uploaded to both, but you should now use the http://security.debian.org lines.
-
-Note that while all of Debian''s architectures are supported, we may
release
-an advisory before fixed packages have built for all supported
-architectures. If so, the missing builds will become available as they
-complete.
-
-Debian developers who would like to upload fixes for security holes in
-testing to the repository can do so, following the instructions on our web
-site. 
-
-Finally, we are still in the process of working out how best to serve users
-of testing and keep your systems secure, and we welcome comments and
-feedback about ways to do better. You can reach the testing security team
-at secure-testing-team at lists.alioth.debian.org.
-
-For more information about the testing security team, see our web site.
-<http://testing-security.debian.net/>.

Deleted: doc/bits_2007_10_x
==================================================================---
doc/bits_2007_10_x	2011-01-18 02:17:42 UTC (rev 15916)
+++ doc/bits_2007_10_x	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,158 +0,0 @@
-Hi fellow developers,
-
-We finally got around to sending this email to inform you about the
-current state of the Testing Security team and its work.
-
-If you at any stage have questions about the Testing Security team,
-please feel free to come to #debian-security on OFTC or write an email to
-secure-testing-team at lists.alioth.debian.org .
-
-
-
-Security status of testing
---------------------------
-
-Thanks to an increased size of our team, Debian Lenny is in good shape with
-respect to security and has been so for some time. We expect to be able to
-keep up this level of security support (at least) until the release of Lenny.
-
-In the weeks immediately after the release of Etch there were some security
-support problems for testing. We hope to improve our processes so that we
won''t
-run into the same problems after the release of Lenny. There will be another
-announcement about the state of these efforts well before Lenny''s
release.
-
-Our web page[0] has been updated to reflect the current status.
-
-
-
-New announcement mails
-----------------------
-
-Previously we were mimicing the announcement method that Stable security
-uses by providing DTSAs (Debian Testing Security Advisories). However,
-these were only prepared for issues that required us to manually prepare
-package updates, thereby forcing a package into testing that would not
-otherwise migrate automatically in a reasonable time-frame. This resulted
-in very infrequent DTSAs because most of the security issues were dealt
-with by fixed packages migrating from unstable to testing.
-
-Therefore, we set up daily announcements (delivered to the
-announcement mailinglist[1]), which include all new security fixes for
-the testing distribution. Most commonly the email shows the migrated
-packages. If there has been a DTSA issued for a package, this will
-show up as well.
-
-In some rare cases, the Testing Security team asks the release
-managers to remove a package from testing, because a security fix in a
-reasonable amount of time seems to be unlikely and the package should
-not be part of testing in our opinion. In this case, the email will
-additionally include information about the removal.
-
-
-
-Efforts to fix security issues in unstable
-------------------------------------------
-
-The Testing Security team works mainly on assigned CVE numbers but
-also follows security relevant bugs reported via the BTS. If you
-encounter a security problem in one of your packages, which does not
-have a CVE number yet, please contact the Testing Security team.  It
-is important to have a CVE id allocated, because they allow us to
-track the security problem in all Debian branches (including Debian
-stable).  When you upload a security fix to unstable, please also
-include the CVE id in your changelog and set the urgency to high. The
-tracker used by both the Testing and Stable Security teams, can be
-found on this webpage[2].
-
-The main task of the Testing Security team is to review CVE id
-relevance to Debian, informing Debian maintainers by filing bugs to
-the BTS (if not already done) and chasing the security fix to move it
-faster into testing.  Whenever possible, we try to provide patches and
-sometimes also NMU the packages in unstable. Please do not regard an
-NMU by the Testing Security team as a bad sign. We try to assist you
-in the best way to keep Debian secure. Also keep in mind that not all
-security related problems have a grave severity, so do not be
-surprised if a normal bug in the Debian BTS results in assigning a CVE
-id for it.  An up to date overview of unresolved issues in unstable
-can be found on the tracker website[3].
-
-
-
-Efforts to fix security issues in testing
------------------------------------------
-
-Our efforts to keep testing secure are primarily focused around
-letting fixed packages migrate from unstable. In order to
-ensure this migration process, we are in close contact with the
-release team and request priority bumps to speed up the
-migration. Sometimes a package is kept from migrating due to a
-transition, the occurrence of new bugs in unstable, buildd issues or
-other problems. In these cases, the Testing Security team considers
-the possibility of issuing a DTSA. We always appreciate it when the
-maintainer contacts us about their specific security problem. When we
-are in communication then we can assist by telling you whether to wait
-for migration or to prepare an upload to testing-security. For non-DDs,
-these uploads can be sponsored by every DD, preferable by a member of
-the Testing Security team. If you get a go for an upload to
-testing-security by one of us, please follow the guidelines on the
-webpage[4]. If we feel the need to issue a DTSA and were not contacted
-by the maintainer, we normally go ahead and upload ourselves, although
-efforts by maintainer to be involved in this process is much preferred.
-
-An up to date overview of unresolved issues in testing can be found on
-the tracker website[5].
-
-
-
-Embedded code copies
---------------------
-
-There are a number of packages including source code from external
-libraries, for example poppler is included in xpdf, kpdf and others.
-To ensure that we don''t miss any vulnerabilities in packages that do
so
-we maintain a list[6] of embedded code copies in Debian. It is preferable
-that you do not embed copies of code in your packages, but instead link
-against packages that already exist in the archive. Please contact us about
-any missing items you know about.
-
-
-
-Some statistics
----------------
-
-* 35 DTSAs had been issued in 2007 so far for over 139 CVE ids
-* 39 NMUs were uploaded in the last two months to fix security flaws
-* 49 security related uploads migrated to testing in the last month for 71 CVE
ids
-* 5500 CVE ids had been processed by the team so far for this year
-
-
-
-New Testing Security Members
-----------------------------
-
-New members are constantly added to the team. The most recent additions are
-Nico Golde, Steffen Joeris, and Thijs Kinkhorst. The circle of team members
-who may approve releases to the testing-security repository has also been
-enlarged by Stefan Fritsch (since May), Nico Golde and Steffen Joeris
-(both added recently).
-
-If you are interested in joining the team, we always need more people,
-and it''s not very hard to contribute in very small ways that have
large
-impacts! Contact us if you are interested. You may want to also look at
-our helping page[7].
-
-So far so good. We hope to keep you updated on testing security issues
-more regularly.
-
-Yours,
-Testing Security team
-
-
-[0]: http://testing-security.debian.net/
-[1]: http://lists.alioth.debian.org/mailman/listinfo/secure-testing-announce
-[2]: http://security-tracker.debian.net/tracker/
-[3]: http://security-tracker.debian.net/tracker/status/release/unstable
-[4]: http://testing-security.debian.net/uploading.html
-[5]: http://security-tracker.debian.net/tracker/status/release/testing
-[6]:
http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=file&rev=0&sc=0
-[7]: http://testing-security.debian.net/helping.html

Deleted: doc/bits_2008_06_x
==================================================================---
doc/bits_2008_06_x	2011-01-18 02:17:42 UTC (rev 15916)
+++ doc/bits_2008_06_x	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,146 +0,0 @@
-Hi fellow developers,
-
-It''s been some time since our last email. Much has happened since then
-with regards to the security support of Debian''s testing distribution.
-
-
-General security support for testing
-------------------------------------
-
-The Debian Testing Security team is very near to providing full
-security support for the testing distribution. At the time of the last
-email, two blockers for full security support were present. However,
-we now are able to process embargoed issues (more on that below), so
-we are happy to announce that only one blocker remains. The only
-remaining blocker for full security support at this point is the
-kernel.  We are talking to the kernel security team about providing
-testing-security support, but at the moment this task lacks
-manpower. If you are willing to work on this, please feel free to
-contact us. Otherwise, in terms of security at this point we recommend
-using the stable kernel or if that is not an option, the unstable
-kernel.  Also, we would like to state that packages that are not
-security supported for stable are likewise unsupported for
-testing. This list includes all packages in contrib and non-free, as
-well as the ones that are marked unsupported (for example,
-kfreebsd). The maintainers are solely responsible for security and
-there won''t be any DTSAs for such packages.
-
-
-Security status of the current testing distribution (lenny)
------------------------------------------------------------
-
-With some pride we can say that testing has never been in such good
-shape security wise. The tracker reflects very accurately the current
-known security issues in the testing distribution[0]. Our new
-announcement emails[1] provide a notification for users whenever a new
-security fix reaches testing, whether through migration from unstable
-or DTSA for testing-security. Also fewer packages are getting removed
-from testing because of security issues.
-
-In order to reach a wider audience with security updates for testing
-and due to the beta1 release of the lenny installer including the
-testing-security repository in the apt-sources, this new mailing list
-was created. We highly recommend that every user who runs Debian
-testing and is concerned about security subscribes[1] to this list
-
-Note: this list is a replacement of the old secure-testing-announce
-list hosted on alioth which has been removed.
-
-
-Security status of the next testing distribution (lenny+1)
-----------------------------------------------------------
-
-After the release of lenny, there will probably be no security support
-for the new testing distribution for some time. It is not clear yet
-how long this state will last. Users of testing who need security
-support are advised to change their sources.list entries from
-"testing" to "lenny" now and only switch to lenny+1 after
the begin of
-its security support is announced. There will be another announcement
-with more details well before the release of lenny.
-
-
-Embargoed issues and access to wider security information
----------------------------------------------------------
-
-Parts of the Testing Security Team have been added to the
-team at security.debian.org alias and are thus also subscribed to the
-vendor-sec mailing list where embargoed security issues are
-coordinated and discussed between Linux vendors before being released
-to the public. The embargoed security queue on security-master will be
-used to prepare DTSAs for such issues. This is a major change as the
-Testing Security Team was not able to prepare updates for security
-issues under embargo before. If a DTSA was prepared for an embargoed
-issue in your package, you will either be contacted by us before the
-release or you will be notified through the BTS. Either way, you will
-most likely get an RC bug against your package including the patch
-used for the DTSA. This way you can prepare updates for unstable and
-the current unfixed unstable package does not migrate to testing,
-where it would overwrite the DTSA.
-
-
-Freeze of lenny coming up
--------------------------
-
-With the lenny release approaching, the Debian release team will at
-some stage freeze the testing archive. This means it is even more
-important to stay in close contact with the Debian Testing Security
-team to coordinate security updates for the testing distribution. If
-one of your packages is affected by an unembargoed security issue,
-please contact us through the public list of the team[2] and fix the
-issue in unstable with high urgency. Please send as much information
-as possible, including patches, ways to reproduce the issue and
-further descriptions. If we ask you to prepare a DTSA, please follow
-the instructions on the testing-security webpage[3] and go ahead with
-the upload.  If your package is affected by an embargoed issue, email
-the private list[4] and if we should ask you to upload a DTSA, use the
-embargoed upload queue (which is the same than for stable/oldstable).
-
-
-Handling of security in the unstable distribution
--------------------------------------------------
-
-First of all, unstable does not have official security support. The
-illusion that the Debian Testing Security team also officially
-supports unstable is not true. Security issues in unstable, especially
-when the package is not in testing, are not regarded as high urgency
-and are only dealt with when there is enough spare time.
-
-However, it is true that most of our security updates migrate through
-unstable to prevent doubled workload. For this purpose, we urge every
-maintainer to upload their security fixes with high urgency and
-mention the CVE ids (if given) in their changelogs.  Because we let
-fixes migrate, it often happens that we NMU packages. An up to date
-list of NMUs done by the security team can be found in our
-repository[5]. These NMUs are done as the need arises and do not
-always follow the given NMU rules, because security updates are
-treated with higher urgency. 
-
-
-Call for new members:
----------------------
-
-The team is still looking for new members. If you are interested in
-joining the Debian Testing Security team, please speak up and either
-write to the public mailing list[2] or approach us on the internal
-mailing list[6]. Note that you do not have to be a DD for all tasks.
-Check out our call for help[7] for more information about the tasks
-and the requirements if you want to join the team. We also look for
-people with experienced knowledge regarding the kernel. We would like
-to start security support for the kernel packages in testing and
-prepare DTSAs for the unembargoed kernel issues. For this task, it
-would be good to have one or two designated people in the Debian
-Testing Security team to only concentrate on this task. If you are
-interested, please speak up.
-
-
-Yours,
-Testing Security 
-
-[0]: http://security-tracker.debian.net/tracker/status/release/testing
-[1]: http://lists.debian.org/debian-testing-security-announce
-[2]: secure-testing-team at lists.alioth.debian.org
-[3]: http://testing-security.debian.net/uploading.html
-[4]: team at security.debian.org
-[5]:
http://svn.debian.org/wsvn/secure-testing/data/NMU/list?op=file&rev=0&sc=0
-[6]: team at testing-security.debian.net
-[7]: http://lists.debian.org/debian-devel-announce/2008/03/msg00007.html

Copied: doc/historic/README (from rev 15916, data/README)
==================================================================---
doc/historic/README	                        (rev 0)
+++ doc/historic/README	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,55 @@
+The checklist program can be run on a system with madison available to
+check vulnerability info from the list files against what packages are in
+testing. Also the updatelist is used by the Makefile to update the lists
+with new info from Mitre. So the various list files need a common, machine
+parsable format. That format is:
+
+begin claimed by foo
+
+[date] id description
+	{id id id}
+	UPCASE: text
+	- package [version] (note; note; note)
+
+end claimed by foo
+
+
+Without writing a format grammar, because this is really rather ad-hoc and
+probably will be replaced with something better:
+
+[date]
+	The date of the advisory in the form dd Mmm YYYY (01 Nov 2004).
+	Optional, only given for DSAs at the moment.
+id
+	DSA-nnn-n, CVE-YYY-nnnn, etc
+description
+	Pretty much freeform description of the problem. Short and optional.
+	By convention, if it''s taken from upstream data source
+	automatically, it will be in parens.  If you want to use a different
+	description, put it in square brackets instead.
+{id id id}
+	This is used to link to other ids that describe the same hole.
+	Generally used to link DSAs to CVEs and back.
+UPCASE
+	Any word in upper case, typically NOTE, HELP, TODO, RESERVED,
+	REJECTED, NOT-FOR-US.
+	May be repeated for each entry.
+- package [version] (note; notes; note)
+	Indicates that the problem is fixed in the given version of the
+	package. May repeat for other packages. If the problem is unfixed,
+	use "<unfixed>" as the version. If the problem
doesn''t affect Debian,
+	use "<not-affected>" as the version. If the problem only
affects
+	shipped releases, for which the stable security team provides
+	security support and the affected package has meanwhile been removed
+	from the archive use "<removed>" as the version.  If the
problem
+	affects a particular release, prepend "[release]" before the
+	"- package" to reflect as much.
+
+	The notes can be freeform, but some are understood by the tools,
+	including "bug #nnnnn", "bug filed", and "high",
+        "medium", "low", "unimportant" and
"unknown" urgencies.
+
+begin claimed by foo
+end claimed by foo
+	Marks a set of items that are being checked by someone.
+	Used to avoid duplicate work.

Copied: doc/historic/TODO (from rev 15916, TODO)
==================================================================---
doc/historic/TODO	                        (rev 0)
+++ doc/historic/TODO	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,50 @@
+* Set up for DTSAs
+
+  - Auto moderation of developer signed mails to -announce.
+
+  - sndadvisory should remove TODO lines from the list file since the
+    advisory is complete
+
+  - merge sndadvisory into dtsa script?
+
+  - web DTSA pages should be built on the fly using the metadata in DTSA/
+    so we don''t have to update things in two places when making a
change,
+    and so releasing a DTSA does not involve copying html files around
+
+  - The dtsa script should have support for updating the list file
+    when running it on an advisory that it''s already been run on
before.
+    This would facilitate issuing asvisories, which often takes a few runs
+    before the final one is sent. Alternatively, get rid of the DTSA/list
+    file (do we need it for anything really?)
+
+* Merge stuff into security.debian.org. Long term, but we need to keep in
+  mind that the current archive setup is just to get bootstrapped.
+
+* Web overview
+  - checklist setup for unstable needs to be fixed to ignore Hurd
+
+* Florian''s overview should be moved to secure-testing.debian.net, but
+  Florian wants to resolve some issues before.
+
+* Write the script that digs through the security bugs
+
+* Write the script that handles the transfer between secure-testing and testing
+  wrt incomplete archs (aba)
+
+* Improve the developer''s reference wrt security bugs (micah)
+
+* Document that finalized syntax
+
+* Review open security bugs and tag the wrt versioned bug tracking
+
+* Create a repo of security patches
+
+* Retroactive updating of the list for not-affected and others
+
+* Document all our stuff and work
+
+* Implement the HELP tag and add it to some outstanding issues
+
+* Link source package specific overview into the PTS
+
+

Copied: doc/historic/announce (from rev 15916, doc/announce)
==================================================================---
doc/historic/announce	                        (rev 0)
+++ doc/historic/announce	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,133 @@
+Subject: forming a security team for testing
+
+I''ve been talking to people about the idea of forming a security team
for
+the testing distribution for several months, and there seems to be enough
+interest in improving testing''s security to make such a team a
reality.
+Most of the people in the CC list have indicated interest in the existence
+of a testing security team; we''re interested in testing''s
security for
+diverse reasons including: use of testing at work, shipping products based
+on testing, hoping to base derived Deban distributions on testing rather
+than stable, wanting testing to be a viable choice for Debian users, and
+so on.
+
+The team will consist of Debian developers and possibly others. Unless a
+member of the Debian security team joins the Debian testing security team,
+none of us will have any privileged information about future security
+announcements. Anyone with interest and experience with security issues is
+welcome to join the team.
+
+To talk about how I think this team would work on testing''s security,
I
+need to talk about two distinct stages, before the sarge release, and
+after.
+
+Right now we''re at a point in the sarge release cycle where most of
the
+focus of a testing security team needs to be on identifying and fixing
+sarge''s security problems and getting it ready for release. This means
+checking to make sure that security problems that have already been fixed
+in unstable and stable do not continue to affect testing, as well as
+dealing with new holes. I don''t think Debian has really invested much
+effort into this in past releases, but if we want sarge to be a secure
+release from the beginning, it''s important to do it.
+
+If we do that work now, then after sarge is released, we will only need to
+worry about keeping track of new security holes and releasing security
+advisories.
+
+Work before sarge''s release:
+---------------------------
+
+Some work on checking sarge for old security issues has already been done.
+With help from some of the people in the CC list, I coordinated a scan of
+every DSA since woody''s release and we checked all 450 DSAs to see if
fixes
+for those security holes had reached testing. Suprisingly, we found some
+security holes that had not gotten fixed in testing in a year or more,
+though those were the exceptions.
+
+I''ve continued to do this checking as each new DSA is released, as
well as
+filing bugs, working with the security team and Release Managers, and doing
+a few NMUs to get the fixes in. The current list of unfixed DSAs sarge is:
+
+	joeyh at newraff:~/sarge-checks>./checklist.pl DSA/list 
+	kpdf (unfixed; bug #278173) for DSA-573-1
+	gpdf 2.8.0-1 needed, have 2.8.0-0.1 for DSA-573-1
+	libpng3 1.2.5.0-9 needed, have 1.2.5.0-8 for DSA-571-1
+	kdelibs 4:3.2.3-3.sarge.1 needed, have 4:3.2.3-2 for DSA-539
+
+But checking DSAs is not a complete check of known security issues that
+might still be lurking in sarge. To do a really complete scan means looking
+through old non-DSA advisories as far back as is reasonable or doable. I
+think doing this scan and the following up on it to fix things would be a
+good first step for the team, and a way to begin figuring out how the team
+will work together.
+
+Mitre has a fairly comprehensive list of security problems in their list of
+CAN numbers[1]. There have been about 1000 CANs allocated this year, some
+of them are not released yet, some were covered by the DSAs and I''ve
+checked a few hundred, so there are about 400 left. I think 4 or 5 people
+could check these in a reasonable time period, and maybe do 2003 as well.
+So if you''re interested in checking some of the CANs to see if they
are
+fixed in sarge, here''s what to do:
+
+ - Sign up for an alioth account if you don''t have one.
+ - Send me your userid to be added to the secure-testing project on alioth.
+ - svn co svn+ssh://svn.debian.org/svn/secure-testing/sarge-checks
+ - Edit the CAN/list file and claim a range of CANs to check. Note that
+   CANs that have already been checked as part of the DSA checks are so
+   marked. Commit the file.
+ - Go through your claimed CANs and check changelogs, advisories, do
+   testing, whatever is needed to satisfy yourself whether sarge is
+   vulnerable or not, and record your findings in the CANs file.
+ - If it''s also not fixed in sid, then be sure to file a RC bug; if
it''s
+   fixed in sid but not in sarge, be sure to record it as a critical issue
+   on the Release Managers'' sarge issue tracker here:
+   http://www.wolffelaar.nl/~sarge/
+   Do other followup as appropriate to get the fix into sarge.
+
+Along with looking for old unfixed holes in sarge and working on getting
+them fixed, we should also keep up-to-date with tracking new holes as
+they''re announced.
+
+Work after sarge''s release:
+--------------------------
+
+By the time sarge releases, I hope to already have a team that has worked
+together on getting sarge secure, and we''ll have a testing
distribution
+with no old security holes in it. This would be a great time to start
+regular security updates for testing. I''ve been considering some
acheivable
+goals for the testing security team, and come up with this list:
+
+ - Provide timely security updates for testing, with fixes being made
+   available no more than four days after a DSA is released.
+ - Work with maintainers to include security fixes from unstable
+   that do not have DSAs.
+ - Maintain a public database and statistics about the current state of
+   security in testing.
+
+Exactly how we would handle doing security updates for testing will have to
+be decided by the team. We will probably want to release gpg signed DTSA
+(Debian Testing Security Advisories) to a mailing list and web site. It
+seems likely that we could use the testing-proposed-updates queue to build
+updates, if it gets set up for all arches and continues to work after the
+sarge release. For tracking issues, we may need to come up with our own
+system, or we may be able to use the BTS, it if gets the promised version
+tracking support added to it. We might want to set up our own security
+repository separate from testing, or not.
+
+I think it''s important that the team not rely on others in Debian to
do the
+work for infrastructure we need; if it''s available then great, but if
not
+we should be prepared to work around it ourselves.
+
+While it''s again up to the eventual team to decide for sure, I suggest
that
+we build security updates against the packages in testing. I also suggest
+that unlike security updates to package in stable, we should most often not
+backport fixes to the versions of packages in testing. More often we will
+simply take the fixed package from unstable, recompile it if necessary, and
+qualify it for the testing distribution. This may involve upgrading to new
+upstream releases, and so there''s a chance our updates will introduce
new
+bugs. Still, that''s not as bad as unfixed security holes, and for a
small
+team with limited manpower, this is a useful shortcut. We can make sure
+that our users realise that using our security updates can expose them to
+upgrade bugs.
+
+[1] http://cve.mitre.org/cve/candidates/downloads/full-can.html
+

Copied: doc/historic/announce.2 (from rev 15916, doc/announce.2)
==================================================================---
doc/historic/announce.2	                        (rev 0)
+++ doc/historic/announce.2	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,127 @@
+Subject: announcing the beginning of security support for testing
+
+---------------------------------------------------------------------------
+Debian Testing Security Team                            September 9th, 2005
+secure-testing-team at lists.alioth.debian.org
+http://testing-security.debian.net/
+---------------------------------------------------------------------------
+
+Security support for testing
+
+The Debian testing security team is pleased to announce the beginning of
+full security support for Debian''s testing distribution. We have spent
the
+past year building the team, tracking and fixing security holes, and
+creating our infrastructure, and now the final pieces are in place, and 
+we are able to offer security updates and advisories for testing.
+
+We invite Debian users who are currently running testing, or who would like
+to switch to testing, to subscribe to the secure-testing-announce mailing 
+list, which will be used to announce security updates.
+<http://lists.alioth.debian.org/mailman/listinfo/secure-testing-announce>
+
+We also invite you to add the following lines to your apt sources.list file,
+and run "apt-get update && apt-get upgrade" to make the
security updates
+available.
+
+deb http://secure-testing.debian.net/debian-secure-testing
etch/security-updates main contrib non-free
+deb-src http://secure-testing.debian.net/debian-secure-testing
etch/security-updates main contrib non-free
+
+Alternatively, replace "secure-testing.debian.net" in the above lines
with
+a mirror near you:
+
+	ftp.de.debian.org         (located in Germany)
+	ftp.nl.debian.org         (located in the Netherlands)
+	the.earth.li              (located in UK)
+	ftp2.jp.debian.org        (located in Japan)
+	farbror.acc.umu.se        (located in Sweden)
+
+Some initial advisories have already been posted to the list and are already
+available in the repository. These include:
+
+[DTSA-1-1] New kismet packages fix remote code execution
+[DTSA-2-1] New centericq packages fix multiple vulnerabilities
+[DTSA-3-1] New clamav packages fix denial of service and privilege escalation
+[DTSA-4-1] New ekg packages fix multiple vulnerabilities
+[DTSA-5-1] New gaim packages fix multiple remote vulnerabilities
+[DTSA-6-1] New cgiwrap packages fix multiple vulnerabilities
+[DTSA-7-1] New mozilla packages fix frame injection spoofing
+[DTSA-8-1] New mozilla-firefox packages fix several vulnerabilities
+[DTSA-9-1] New bluez-utils packages fix bad device name escaping
+[DTSA-10-1] New pcre3 packages fix buffer overflow
+[DTSA-11-1] New maildrop packages fix local privilege escalation
+[DTSA-12-1] New vim packages fix modeline exploits
+[DTSA-13-1] New evolution packages fix format string vulnerabilities
+
+Note that while all of Debian''s architectures are supported, we may
release
+an advisory before fixed packages have built for all supported
+architectures. If so, the missing builds will become available as they
+complete.
+
+We are not currently issuing advisories for security fixes that reach
+testing through normal propagation from unstable, but only for security
+fixes that are made available through our repository. So users of testing
+should continue to upgrade their systems on a regular basis to get such
+security fixes. We might provide information about security issues that
+have been fixed through regular testing propagation in the future, though.
+
+Note that this announcement does not mean that testing is suitable for
+production use. Several security issues are present in unstable, and an
+even larger number are present in testing. Our beginning of security
+support only means that we are now able to begin making security fixes
+available for testing nearly as quickly as for unstable. The testing
+security team''s website has information about what security holes are
still
+open, and users should use this information to make their own decisions
+about whether testing is secure enough for them.
+
+Finally, we are still in the process of working out how best to serve users
+of testing and keep your systems secure, and we welcome comments and
+feedback about ways to do better. You can reach the testing security team
+at secure-testing-team at lists.alioth.debian.org.
+
+If you want to become a mirror, please see
+http://testing-security.debian.net/mirroring.html
+
+Debian developers who would like to upload fixes for security holes in
+testing to the repository can do so, following the instructions on our web
+site. 
+
+For more information about the testing security team, see our web site.
+<http://testing-security.debian.net/>.
+
+----------------------------------------------------------------------------
+
+The archive signing key that is used to sign the apt repository is
+included below and can also be downloaded from
+http://testing-security.debian.net/ziyi-2005-7.asc
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v1.4.1 (GNU/Linux)
+
+mQGiBEMM7wgRBACs/rcYtu++PqBV5t6qTf9FsjJYZV4OUoQmtK849PdHUoVONh/b
+yz0vmP4QPCJXraFYiiiaur8WLcOphwY3DFaz0quozxl3pZfJjN27qDdTTDUKk1Kq
+zFQYTsDaXjSh0nRGW3gFmbyIqTL8sVGOAAz2KbrtLEQE11qYZjzvylEf4wCgv6ss
+HgQ7AcSBjpvm72e9PvSuDhMD/1kV0Snq9ilvCv7QLHBo/JnNgiCwxh5nEnPWHYjo
+SB0I99nuFMAzooAXTQhU3Hx1/sdZ3SMk1hWwZCPI0iNqESH2a3ib0YZt0DycWa3Y
+KxXIJet92u3ApSMVbp6OzzL7REoNCAgg6F/lrl+lVtnHbKiKBMZlKMsp+kQLSXqr
+Ki0pA/wIkkp7mJ7IiVS0fy9gueuiLqJKR6+i092J0RXsQesQX4OTC2DY3IICB22Q
+HfE8WNVZ2iPuWK0ymg6GqAHplp7bfVZMzfMSTMc+hj9WnmEVRRjLH66tsq1XHGEQ
+qg/mbkmeXwUwxAT1WGClcRWJqODmWE7KhkjKwGklYgzBoxwqkLRDc2VjdXJlLXRl
+c3RpbmcgQXJjaGl2ZSBLZXkgMjAwNS03IDxrYXRpZUBzZWN1cmUtdGVzdGluZy5k
+ZWJpYW4ubmV0PohkBBMRAgAkBQJDDO8IAhsDBQkElVcABgsJCAcDAgMVAgMDFgIB
+Ah4BAheAAAoJEJRqpuGHIucecvgAoK3nnF0yEwpNeQASyerh4wxRblZzAJ9h8rEF
+YldbZt/zYA53k2/y2m+s7LkCDQRDDO8gEAgAm1Y/a//sVe6fEANvLc5M5pEsoRkP
+LNKcH1O/og2mID8/gBV99LRfRnjcV8xhF5cWIlb4Es3KvQxmvxo6zGEfsMJWoezq
+H+2agIra78dfb0B1AyHuvwSRMc9sVy+3CuegM8bD3ss+4ta3rNLChpVrE8DxJZum
+ecqkNSQVOkqeAOl2JIQ/xBkLg1hjQA8bXW5AiUu4/XAQAe04w7YNfdsApeCfpKEW
+Atg54CD9uRbfSwnd2uYHYcosmBMhryNrHy27RkyS0BFWaL/1gfBqua7VujcnCm6S
+nbhB4t3vk/AnEsPJixtW/tOC3a3BaPqGsTq848e/PzmWY/8y9mvXwbxq5wADBQgA
+gNtB3u8TCN2Z4wkKrg19LohivQzJCXFfRi2ZydOe9E3SbSi6ggthjvGhHv2lTHEu
+e/4wBOta3a9pUpVdMgRFL1UuJy3nPd1yPC0dOegJj+lMkeMGcdKolJUMdoA+ieZ2
+lwkrT1b5GdFBSRn8hsuRtZi69QtzoHzDR5lg9ynwTJ+mLlO8r83HmdxbXsnmGlxy
+ZWRoqiSIl7mRLHp2tuFw9chgJ1nqwewTmCj85Aj/YsbGmqOJcnp98Jk0GDiP/le4
+rktZAqG2blwVpC2DLLiQSqcYS5jjq/iiGnYEIVG+nPa/29OuoX40zwKqBcy5I8rJ
+ZIq2hzbazsyg2Sd3vhmZuohPBBgRAgAPBQJDDO8gAhsMBQkElVcAAAoJEJRqpuGH
+IuceRqUAn3Q8msRUTsp882QINWyy5fqTehb5AJ9+kz3xq+7ooAwkdgpNOiz7ogxp
+Qg=+=KBNL
+-----END PGP PUBLIC KEY BLOCK-----

Copied: doc/historic/announce.3 (from rev 15916, doc/announce.3)
==================================================================---
doc/historic/announce.3	                        (rev 0)
+++ doc/historic/announce.3	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,46 @@
+X-pseudo-subject: For those who care about testing security
+Subject: Testing security archive move
+
+---------------------------------------------------------------------------
+Debian Testing Security Team                                 May 12th, 2006
+secure-testing-team at lists.alioth.debian.org
+http://testing-security.debian.net/
+---------------------------------------------------------------------------
+
+Testing security archive move
+
+The Debian testing security team is pleased to announce the integration of
+the secure testing archive to http://security.debian.org
+
+We invite Debian users who are currently running testing, or who would like
+to switch to testing, to subscribe to the secure-testing-announce mailing 
+list, which will be used to announce security updates.
+<http://lists.alioth.debian.org/mailman/listinfo/secure-testing-announce>
+
+We also invite you to add the following lines to your apt sources.list file,
+and run "apt-get update && apt-get upgrade" to make the
security updates
+available.
+
+deb http://security.debian.org etch/updates main contrib non-free
+deb-src http://security.debian.org etch/updates main contrib non-free
+
+This replaces the previous http://secure-testing.debian.net/ lines which should
+no longer be used. There will be a transition period where packages are
+uploaded to both, but you should now use the http://security.debian.org lines.
+
+Note that while all of Debian''s architectures are supported, we may
release
+an advisory before fixed packages have built for all supported
+architectures. If so, the missing builds will become available as they
+complete.
+
+Debian developers who would like to upload fixes for security holes in
+testing to the repository can do so, following the instructions on our web
+site. 
+
+Finally, we are still in the process of working out how best to serve users
+of testing and keep your systems secure, and we welcome comments and
+feedback about ways to do better. You can reach the testing security team
+at secure-testing-team at lists.alioth.debian.org.
+
+For more information about the testing security team, see our web site.
+<http://testing-security.debian.net/>.

Copied: doc/historic/bits_2007_10_x (from rev 15916, doc/bits_2007_10_x)
==================================================================---
doc/historic/bits_2007_10_x	                        (rev 0)
+++ doc/historic/bits_2007_10_x	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,158 @@
+Hi fellow developers,
+
+We finally got around to sending this email to inform you about the
+current state of the Testing Security team and its work.
+
+If you at any stage have questions about the Testing Security team,
+please feel free to come to #debian-security on OFTC or write an email to
+secure-testing-team at lists.alioth.debian.org .
+
+
+
+Security status of testing
+--------------------------
+
+Thanks to an increased size of our team, Debian Lenny is in good shape with
+respect to security and has been so for some time. We expect to be able to
+keep up this level of security support (at least) until the release of Lenny.
+
+In the weeks immediately after the release of Etch there were some security
+support problems for testing. We hope to improve our processes so that we
won''t
+run into the same problems after the release of Lenny. There will be another
+announcement about the state of these efforts well before Lenny''s
release.
+
+Our web page[0] has been updated to reflect the current status.
+
+
+
+New announcement mails
+----------------------
+
+Previously we were mimicing the announcement method that Stable security
+uses by providing DTSAs (Debian Testing Security Advisories). However,
+these were only prepared for issues that required us to manually prepare
+package updates, thereby forcing a package into testing that would not
+otherwise migrate automatically in a reasonable time-frame. This resulted
+in very infrequent DTSAs because most of the security issues were dealt
+with by fixed packages migrating from unstable to testing.
+
+Therefore, we set up daily announcements (delivered to the
+announcement mailinglist[1]), which include all new security fixes for
+the testing distribution. Most commonly the email shows the migrated
+packages. If there has been a DTSA issued for a package, this will
+show up as well.
+
+In some rare cases, the Testing Security team asks the release
+managers to remove a package from testing, because a security fix in a
+reasonable amount of time seems to be unlikely and the package should
+not be part of testing in our opinion. In this case, the email will
+additionally include information about the removal.
+
+
+
+Efforts to fix security issues in unstable
+------------------------------------------
+
+The Testing Security team works mainly on assigned CVE numbers but
+also follows security relevant bugs reported via the BTS. If you
+encounter a security problem in one of your packages, which does not
+have a CVE number yet, please contact the Testing Security team.  It
+is important to have a CVE id allocated, because they allow us to
+track the security problem in all Debian branches (including Debian
+stable).  When you upload a security fix to unstable, please also
+include the CVE id in your changelog and set the urgency to high. The
+tracker used by both the Testing and Stable Security teams, can be
+found on this webpage[2].
+
+The main task of the Testing Security team is to review CVE id
+relevance to Debian, informing Debian maintainers by filing bugs to
+the BTS (if not already done) and chasing the security fix to move it
+faster into testing.  Whenever possible, we try to provide patches and
+sometimes also NMU the packages in unstable. Please do not regard an
+NMU by the Testing Security team as a bad sign. We try to assist you
+in the best way to keep Debian secure. Also keep in mind that not all
+security related problems have a grave severity, so do not be
+surprised if a normal bug in the Debian BTS results in assigning a CVE
+id for it.  An up to date overview of unresolved issues in unstable
+can be found on the tracker website[3].
+
+
+
+Efforts to fix security issues in testing
+-----------------------------------------
+
+Our efforts to keep testing secure are primarily focused around
+letting fixed packages migrate from unstable. In order to
+ensure this migration process, we are in close contact with the
+release team and request priority bumps to speed up the
+migration. Sometimes a package is kept from migrating due to a
+transition, the occurrence of new bugs in unstable, buildd issues or
+other problems. In these cases, the Testing Security team considers
+the possibility of issuing a DTSA. We always appreciate it when the
+maintainer contacts us about their specific security problem. When we
+are in communication then we can assist by telling you whether to wait
+for migration or to prepare an upload to testing-security. For non-DDs,
+these uploads can be sponsored by every DD, preferable by a member of
+the Testing Security team. If you get a go for an upload to
+testing-security by one of us, please follow the guidelines on the
+webpage[4]. If we feel the need to issue a DTSA and were not contacted
+by the maintainer, we normally go ahead and upload ourselves, although
+efforts by maintainer to be involved in this process is much preferred.
+
+An up to date overview of unresolved issues in testing can be found on
+the tracker website[5].
+
+
+
+Embedded code copies
+--------------------
+
+There are a number of packages including source code from external
+libraries, for example poppler is included in xpdf, kpdf and others.
+To ensure that we don''t miss any vulnerabilities in packages that do
so
+we maintain a list[6] of embedded code copies in Debian. It is preferable
+that you do not embed copies of code in your packages, but instead link
+against packages that already exist in the archive. Please contact us about
+any missing items you know about.
+
+
+
+Some statistics
+---------------
+
+* 35 DTSAs had been issued in 2007 so far for over 139 CVE ids
+* 39 NMUs were uploaded in the last two months to fix security flaws
+* 49 security related uploads migrated to testing in the last month for 71 CVE
ids
+* 5500 CVE ids had been processed by the team so far for this year
+
+
+
+New Testing Security Members
+----------------------------
+
+New members are constantly added to the team. The most recent additions are
+Nico Golde, Steffen Joeris, and Thijs Kinkhorst. The circle of team members
+who may approve releases to the testing-security repository has also been
+enlarged by Stefan Fritsch (since May), Nico Golde and Steffen Joeris
+(both added recently).
+
+If you are interested in joining the team, we always need more people,
+and it''s not very hard to contribute in very small ways that have
large
+impacts! Contact us if you are interested. You may want to also look at
+our helping page[7].
+
+So far so good. We hope to keep you updated on testing security issues
+more regularly.
+
+Yours,
+Testing Security team
+
+
+[0]: http://testing-security.debian.net/
+[1]: http://lists.alioth.debian.org/mailman/listinfo/secure-testing-announce
+[2]: http://security-tracker.debian.net/tracker/
+[3]: http://security-tracker.debian.net/tracker/status/release/unstable
+[4]: http://testing-security.debian.net/uploading.html
+[5]: http://security-tracker.debian.net/tracker/status/release/testing
+[6]:
http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=file&rev=0&sc=0
+[7]: http://testing-security.debian.net/helping.html

Copied: doc/historic/bits_2008_06_x (from rev 15916, doc/bits_2008_06_x)
==================================================================---
doc/historic/bits_2008_06_x	                        (rev 0)
+++ doc/historic/bits_2008_06_x	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,146 @@
+Hi fellow developers,
+
+It''s been some time since our last email. Much has happened since then
+with regards to the security support of Debian''s testing distribution.
+
+
+General security support for testing
+------------------------------------
+
+The Debian Testing Security team is very near to providing full
+security support for the testing distribution. At the time of the last
+email, two blockers for full security support were present. However,
+we now are able to process embargoed issues (more on that below), so
+we are happy to announce that only one blocker remains. The only
+remaining blocker for full security support at this point is the
+kernel.  We are talking to the kernel security team about providing
+testing-security support, but at the moment this task lacks
+manpower. If you are willing to work on this, please feel free to
+contact us. Otherwise, in terms of security at this point we recommend
+using the stable kernel or if that is not an option, the unstable
+kernel.  Also, we would like to state that packages that are not
+security supported for stable are likewise unsupported for
+testing. This list includes all packages in contrib and non-free, as
+well as the ones that are marked unsupported (for example,
+kfreebsd). The maintainers are solely responsible for security and
+there won''t be any DTSAs for such packages.
+
+
+Security status of the current testing distribution (lenny)
+-----------------------------------------------------------
+
+With some pride we can say that testing has never been in such good
+shape security wise. The tracker reflects very accurately the current
+known security issues in the testing distribution[0]. Our new
+announcement emails[1] provide a notification for users whenever a new
+security fix reaches testing, whether through migration from unstable
+or DTSA for testing-security. Also fewer packages are getting removed
+from testing because of security issues.
+
+In order to reach a wider audience with security updates for testing
+and due to the beta1 release of the lenny installer including the
+testing-security repository in the apt-sources, this new mailing list
+was created. We highly recommend that every user who runs Debian
+testing and is concerned about security subscribes[1] to this list
+
+Note: this list is a replacement of the old secure-testing-announce
+list hosted on alioth which has been removed.
+
+
+Security status of the next testing distribution (lenny+1)
+----------------------------------------------------------
+
+After the release of lenny, there will probably be no security support
+for the new testing distribution for some time. It is not clear yet
+how long this state will last. Users of testing who need security
+support are advised to change their sources.list entries from
+"testing" to "lenny" now and only switch to lenny+1 after
the begin of
+its security support is announced. There will be another announcement
+with more details well before the release of lenny.
+
+
+Embargoed issues and access to wider security information
+---------------------------------------------------------
+
+Parts of the Testing Security Team have been added to the
+team at security.debian.org alias and are thus also subscribed to the
+vendor-sec mailing list where embargoed security issues are
+coordinated and discussed between Linux vendors before being released
+to the public. The embargoed security queue on security-master will be
+used to prepare DTSAs for such issues. This is a major change as the
+Testing Security Team was not able to prepare updates for security
+issues under embargo before. If a DTSA was prepared for an embargoed
+issue in your package, you will either be contacted by us before the
+release or you will be notified through the BTS. Either way, you will
+most likely get an RC bug against your package including the patch
+used for the DTSA. This way you can prepare updates for unstable and
+the current unfixed unstable package does not migrate to testing,
+where it would overwrite the DTSA.
+
+
+Freeze of lenny coming up
+-------------------------
+
+With the lenny release approaching, the Debian release team will at
+some stage freeze the testing archive. This means it is even more
+important to stay in close contact with the Debian Testing Security
+team to coordinate security updates for the testing distribution. If
+one of your packages is affected by an unembargoed security issue,
+please contact us through the public list of the team[2] and fix the
+issue in unstable with high urgency. Please send as much information
+as possible, including patches, ways to reproduce the issue and
+further descriptions. If we ask you to prepare a DTSA, please follow
+the instructions on the testing-security webpage[3] and go ahead with
+the upload.  If your package is affected by an embargoed issue, email
+the private list[4] and if we should ask you to upload a DTSA, use the
+embargoed upload queue (which is the same than for stable/oldstable).
+
+
+Handling of security in the unstable distribution
+-------------------------------------------------
+
+First of all, unstable does not have official security support. The
+illusion that the Debian Testing Security team also officially
+supports unstable is not true. Security issues in unstable, especially
+when the package is not in testing, are not regarded as high urgency
+and are only dealt with when there is enough spare time.
+
+However, it is true that most of our security updates migrate through
+unstable to prevent doubled workload. For this purpose, we urge every
+maintainer to upload their security fixes with high urgency and
+mention the CVE ids (if given) in their changelogs.  Because we let
+fixes migrate, it often happens that we NMU packages. An up to date
+list of NMUs done by the security team can be found in our
+repository[5]. These NMUs are done as the need arises and do not
+always follow the given NMU rules, because security updates are
+treated with higher urgency. 
+
+
+Call for new members:
+---------------------
+
+The team is still looking for new members. If you are interested in
+joining the Debian Testing Security team, please speak up and either
+write to the public mailing list[2] or approach us on the internal
+mailing list[6]. Note that you do not have to be a DD for all tasks.
+Check out our call for help[7] for more information about the tasks
+and the requirements if you want to join the team. We also look for
+people with experienced knowledge regarding the kernel. We would like
+to start security support for the kernel packages in testing and
+prepare DTSAs for the unembargoed kernel issues. For this task, it
+would be good to have one or two designated people in the Debian
+Testing Security team to only concentrate on this task. If you are
+interested, please speak up.
+
+
+Yours,
+Testing Security 
+
+[0]: http://security-tracker.debian.net/tracker/status/release/testing
+[1]: http://lists.debian.org/debian-testing-security-announce
+[2]: secure-testing-team at lists.alioth.debian.org
+[3]: http://testing-security.debian.net/uploading.html
+[4]: team at security.debian.org
+[5]:
http://svn.debian.org/wsvn/secure-testing/data/NMU/list?op=file&rev=0&sc=0
+[6]: team at testing-security.debian.net
+[7]: http://lists.debian.org/debian-devel-announce/2008/03/msg00007.html

Copied: doc/historic/lenny_release (from rev 15916, doc/lenny_release)
==================================================================---
doc/historic/lenny_release	                        (rev 0)
+++ doc/historic/lenny_release	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,35 @@
+Subject: Temporary suspension of testing security support after release of 5.0
(lenny)
+
+Due to the experiences we made after the last stable Debian release, the
+Testing Security Team believes that it will be impossible to provide proper
+security support for the new testing (Debian "squeeze") in the weeks
following
+the release of Debian 5.0 (lenny).  Therefore we will temporarily suspend
+security support for Debian testing after the release.
+
+If you need security support, we strongly recommend that you now change your
apt
+sources.list entries to point to "lenny" instead of
"testing".  This way you
+will automatically stay with "lenny" after its release as stable and
will
+receive the normal security support for Debian stable.  After the begin of
+security support for Debian "squeeze" is announced, you may safely
upgrade to
+testing again.
+
+
+There are two reasons for this suspension:
+
+After a stable release it will take some time to get the security related
buildd
+infrastructure for the new testing in place.  Since many people will be busy
+celebrating the release, we don''t know how long this will take ;-)
+
+In addition to that, we expect that shortly after the release a new libc
+version will be uploaded to unstable, which will block most packages from
+migrating from unstable to testing.  This means that no security fixes will
+reach testing from unstable.  Since the Testing Security Team does not have
+enough members to backport all security fixes to testing, it will be impossible
+to provide proper security support.  After the last stable release (etch) it
+took nearly two months until the new glibc reached testing.
+
+On the other hand, libc blocking most packages from migrating to testing also
+means that the difference between stable and testing will not grow quickly in
+the weeks after lenny release.  Therefore staying with stable should be an
+acceptable solution for most users during that time.  If you absolutely need
+newer packages, you may also consider using unstable instead of testing.

Copied: doc/historic/mopb.txt (from rev 15916, data/mopb.txt)
==================================================================---
doc/historic/mopb.txt	                        (rev 0)
+++ doc/historic/mopb.txt	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,237 @@
+Issues affecting PHP 4 and PHP 5:
+
+41  PHP 5 sqlite_udf_decode_binary() Buffer Overflow Vulnerability
+#TODO(medium) -> for PHP5, php4 uses a seperate php4-sqlite package.
+[MOPB-41-php5.diff]
+
+34  PHP mail() Header Injection Through Subject and To Parameters
+#TODO(medium) -> needs to be fixed, CVE-2007-1718 (php4 & php5, header
+injection possible via some MTAs when set to process the headers for
+recipients), Sarge''s php4 not affected
+[MOPB-34-php5.diff]
+
+30  PHP _SESSION unset() Vulnerability
+#TODO(low) -> hard to trigger remotely, CVE-2007-1700. (php4 & php5,
code execution)
+[MOPB-30-php5.diff]
+
+26  PHP mb_parse_str() register_globals Activation Vulnerability
+#TODO(medium) -> functionally enables register_globals for any future
requests, CVE-2007-1583 (php4 & php5, enables stealth register_globals for
life of process)
+
+22  PHP session_regenerate_id() Double Free Vulnerability
+#TODO(medium) -> locally exploitable to gain access to process memory, hard
to do remotely, CVE-2007-1521 (php4 & php5, code execution)
+[MOPB-22-php5.diff]
+
+10  PHP php_binary Session Deserialization Information Leak  Vulnerability
+#TODO(low) -> Can only leak 127 bytes of data, CVE-2007-1380 (php4 &
php5, heap leak)
+Check, to which extent this was covered by our backports of 5.2.1 patches
+[MOPB-10-php5.diff]
+
+
+
+Issues affecting PHP 4 only:
+
+35  PHP 4 zip_entry_read() Integer Overflow Vulnerability
+#TODO(medium) -> needs to be fixed, CVE-2007-1777 (php4, remote code
execution)
+[MOPB-35-php4.diff]
+
+32  PHP 4.4.5/4.4.6 session_decode() Double Free Vulnerability (U) 
+TODO(medium) -> needs to be fixed in php/etch and php/sarge (remote code
execution)
+[MOPB-32-php4.diff]
+
+04  PHP 4 unserialize() ZVAL Reference Counter Overflow
+TODO (php4 only, gain execute control)
+[MOPB-04-php4.diff]
+
+
+
+Issues affecting PHP 5 only:
+
+45  PHP ext/filter Email Validation Vulnerability
+TODO(low) -> possible email header injections when coupled with other
problems (php5 5.2.0, 5.2.1)
+[MOPB-45-php5.diff]
+
+44  PHP 5.2.0 Memory Manager Signed Comparision Vulnerability
+#TODO(medium) -> remotely exploitable via SOAP interfaces, CVE-2007-1889
(php5 5.2.0 only)
+
+42  PHP 5 php_stream_filter_create() Off By One Vulnerablity
+#TODO(medium) -> needs to be fixed, CVE-2007-1824 (php5, remote code
execution, though haven''t reproduced it)
+[MOPB-42-php5.diff]
+
+23  PHP 5 Rejected Session Identifier Double Free Vulnerability
+#TODO(medium) -> locally exploitable to gain access to process memory, hard
to do remotely, CVE-2007-1522. (php5 5.2.0+, code execution)
+
+19 PHP ext/filter Space Trimming Buffer Underflow Vulnerability
+#TODO(medium) -> for PHP5. CVE-2007-1453 (php5 5.2.0 only, code execution on
big endian)
+
+18  PHP ext/filter HTML Tag Stripping Bypass Vulnerability
+#TODO(medium) -> for PHP5. CVE-2007-1453 (php5 5.2.0 only, can avoid
filters)
+
+17  PHP ext/filter FDF Post Bypass Vulnerability
+#TODO(low) -> ...or possibly "broken as designed". CVE-2007-1452,
(php5 5.2.0 only, can avoid filters)
+
+16  PHP zip:// URL Wrapper Buffer Overflow Vulnerability
+#TODO(medium) -> possible remote data can result in code execution in 5.2.0
which uses the zip handler, CVE-2007-1399. (php5 5.2.0 only, code execution)
+
+14  PHP substr_compare() Information Leak Vulnerability
+#TODO(low) -> corner-case where length+offset > INT_MAX, CVE-2007-1375
(php5, heap leak)
+[MOPB-14-php5.diff]
+
+
+
+
+
+Done or resolved:
+
+
+43  PHP msg_receive() Memory Allocation Integer Overflow Vulnerabilty
+#N/A -> Only triggerable by malicious script, CVE-2007-1890 (php4 &
php5, local code execution, possibly FreeBSD only)
+
+40  PHP imap_mail_compose() Boundary Stack Buffer Overflow Vulnerability
+#Fixed in DSA-1264 and the respective PHP4/PHP5 packages, dupe
CVE-2007-0906/CVE-2007-1825
+
+39  PHP str_replace() Memory Allocation Integer Overflow Vulnerability
+#Fixed in DSA-1264 and the respective PHP4/PHP5 packages, dupe
CVE-2007-0906/CVE-2007-1885
+
+38  PHP printf() Family 64 Bit Casting Vulnerabilities
+#Fixed in DSA-1264 and the respective PHP4/PHP5 packages, dupe
CVE-2007-0909/CVE-2007-1884
+
+37  PHP iptcembed() Interruption Information Leak Vulnerability
+#N/A -> Only triggerable by malicious script, CVE-2007-1883 (php4 &
php5, local code execution)
+
+36  PHP session.save_path open_basedir Bypass Vulnerability
+#N/A -> open_basedir bypasses not supported, CVE-2007-1461
+
+33  PHP mail() Message ASCIIZ Byte Truncation
+#N/A -> This is a bug, but not security-relevant, CVE-2007-1717 (php4 &
php5)
+
+31  PHP _SESSION Deserialization Overwrite Vulnerability
+#N/A -> register_globals not supported, already fixed in DSA-1264, dupe
CVE-2007-0910/CVE-2007-1701 (php4 & php5, very hard to trigger remotely,
code execution)
+
+29  PHP 5.2.1 unserialize() Information Leak Vulnerability
+#N/A -> Only affects PHP 5.2.1, CVE-2007-1649 (heap leak via broken
"S" unserializer, which should maybe be removed from 5.2.1, since it
is only for future compatibility and is totally broken?)
+[MOPB-29-php5.diff]
+
+28  PHP hash_update_file() Already Freed Resource Access Vulnerability
+#N/A -> Only triggerable by malicious script, CVE-2007-1581 (php5, local
malicious stream handler leads to code execution)
+
+27  PHP ext/gd Already Freed Resource Access Vulnerability
+#N/A -> Only triggerable by malicious script, CVE-2007-1582 (php4 &
php5, local malicious error handler leads to code execution)
+
+25  PHP header() Space Trimming Buffer Underflow Vulnerability
+#Fixed in Etch as part of the 5.2.1 backport, dupe CVE-2007-0907/CVE-2007-1584
+
+24  PHP array_user_key_compare() Double DTOR Vulnerability
+#N/A -> Only triggerable by malicious script, CVE-2007-1484 (php4 &
php5, code execution)
+[MOPB-24-php5.diff]
+
+21  PHP compress.bzip2:// URL Wrapper safemode and open_basedir Bypass
Vulnerability
+#N/A -> Safemode and open_basedir bypasses not supported, CVE-2007-1461
+
+20  PHP zip:// URL Wrapper safemode and open_basedir Bypass Vulnerability
+#N/A -> Safemode and open_basedir bypasses not supported, CVE-2007-1460
+
+15  PHP shmop Functions Resource Verification Vulnerability
+#N/A -> Only triggerable by malicious script, could be used to read/write
arbitrary memory, CVE-2007-1376 (php4 & php5, arbitrary memory leakage)
+[MOPB-15-php5.diff]
+
+13  PHP 4 Ovrimos Extension Multiple Vulnerabilities
+#N/A -> Ovrimos support not provided in any debian php packages,
CVE-2007-1379, CVE-2007-1378
+
+12  mod_security POST Rules Bypass Vulnerability
+#N/A -> applies to modsecurity, not packaged for sarge/etch/(sid?),
CVE-2007-1359.
+
+11  PHP WDDX Session Deserialization Information Leak Vulnerability
+#Fixed in DSA-1264. CVE-2007-0908 (php4 & php5, controllable stack leak)
+
+09  PHP wddx_deserialize() String Append Buffer Overflow Vulnerability
+#N/A -> Only applies to a development version in CVS, not a shipped release,
CVE-2007-1381.
+
+08  PHP 4 phpinfo() XSS Vulnerability (Deja-vu)
+N/A -> phpinfo() is a debug function, not be exposed to applications (php4
4.4.3 through 4.4.6 only, phpinfo XSS)
+
+07  Zend Platform ini_modifier Local Root Vulnerability (B)
+N/A -> Only affects the Zend platform
+
+06  Zend Platform Insecure File Permission Local Root Vulnerability
+N/A -> Only affects the Zend platform
+
+05  PHP unserialize() 64 bit Array Creation Denial of Service  Vulnerability
+#Fixed in DSA-1264. CVE-2007-0988 (php4 & php5, limited-time 100% CPU DoS)
+
+03  PHP Variable Destructor Deep Recursion Stack Overflow
+#N/A -> Applications need to impose sanity checks for maximum recursion,
CVE-2007-1285 (php4 & php5, crash only)
+
+02  PHP Executor Deep Recursion Stack Overflow
+#N/A -> Applications need to impose sanity checks for maximum recursion,
CVE-2006-1549 (php4 & php5, crash only)
+
+01  PHP 4 Userland ZVAL Reference Counter Overflow Vulnerability
+#N/A -> Only triggerable by malicious script, CVE-2007-1383 (php4 only, gain
execute control)
+
+
+
+
+(Comments starting with # indicate that information has been fed to the
tracker)
+(Comments starting with TOFIX indicate that a patch has been created or
extracted)
+
+
+# php4 checklist
+
+   Sarge Etch
+41   a    a <- seperate source package php4-sqlite
+35   T    T
+34   /    t
+32   T    T 
+30   /    /
+26   a    a
+22   t    t 
+10   T    T <- seemed already fixed but this completes the patch
+04   T    T
+
+? = more info
+x = fix needed
+* = extracted
+a = patch generated and commited to SVN
+t = didn''t seem affected, but patch makes sense
+T = code tested
+/ = not affected
+
+# PHP5 checklist....
+MOPB   Etch, Unstable  Dapper, Edgy, Feisty, Gutsy       PATCH
+10      p     p[3]      T       T     T       -            *
+14      X     T         T       T     T       -            *
+15      i     T         T       T     -       -            *
+16      p     p         -       -     -       -
+17      -     -         -       -     -       -
+18      X     T         -       -     -       -
+19      X     T         -       -     -       -
+22      X     T         T       T     T       -            *
+23      X     T[5]      X       X     X       -            ?
+24      i     i         T       T     T       X            *
+26      X     T         T       T     T       -            *
+29      -     -         -       -     T       -            *
+30      -     a[4]      T       T     -       -            *
+34      X     a         T       T     T       -            *
+41      X     T         T       T     T       -            ![1]
+42      X     a         T       T     -       -            *
+44      X     a         -       -     -       -
+45      X     T         -       -     T       -            ![2]
+
+* = patch extracted from upstream
+? = no upstream patch found
+! = patch created
+
+X = fixed desired
+a = patch applied
+p = previously fixed
+T = code tested
+- = fix n/a
+i = fix skipped
+
+[1] but the fix in php5 is not right, the call (not the SQLite API) needs
+    to be changed.  For references, here is the upstream "fix":
+   
http://cvs.php.net/viewvc.cgi/php-src/ext/sqlite/libsqlite/src/encode.c?r1=1.5.4.1&r2=1.5.4.1.2.1&pathrev=PHP_5_2
+[2] this needs a CVE assigned
+[3] previously fixed, but the patch adds another check we should have too.
+[4] could not reproduce this problem
+[5] the first hunk of the patch for mopb 22 fixes this.
+

Copied: doc/historic/mops.txt (from rev 15916, data/mops.txt)
==================================================================---
doc/historic/mops.txt	                        (rev 0)
+++ doc/historic/mops.txt	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,64 @@
+Month of PHP security May 2010 status file
+
+001: CVE-2007-1581; Only triggerable by malicious script
+002: External app not in Debian: Campsite
+003: CVE-2010-1866; Should be fixed for Squeeze, doesn''t affect Lenny
(5.3 only)
+004: External app not in Debian: ClanSphere
+005: External app not in Debian: ClanSphere
+006: CVE-2010-1864; Only triggerable by malicious script
+007: External app not in Debian: ClanTiger
+008: CVE-2010-1862; Only triggerable by malicious script
+009: CVE-2010-1861; Only triggerable by malicious script
+010: CVE-2010-1860; Only triggerable by malicious script
+011: External app not in Debian: DeluxeBB
+012: CVE-2010-1868; Only triggerable by malicious script
+013: CVE-2010-1868; Only triggerable by malicious script
+014: CVE-2010-1914; Only triggerable by malicious script
+015: CVE-2010-1914; Only triggerable by malicious script
+016: CVE-2010-1914; Only triggerable by malicious script
+017: CVE-2010-1915; Only triggerable by malicious script
+018: External app not in Debian: EFront
+019: CVE-2010-1916; Serendipity, doesn''t affect Lenny (1.4 onwards),
pinged Thijs
+020: CVE-2010-1916; External app; xinha, Just an ITP: #479708, there are
embedders
+021: CVE-2010-1917; PHP fnmatch() Stack Exhaustion Vulnerability
+022: CVE-2010-2093; Only triggerable by malicious script
+023: no CVE yet; Cacti, pinged Sean Finney
+024: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
+025: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
+026: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
+027: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
+028: CVE-2010-2094; Doesn''t affect Lenny, extension is new enough not
to have (code) users other than PEAR
+029: External app not in Debian: CMSQLITE
+030: External app not in Debian: CMSQLITE
+031: External app not in Debian: e107
+032: CVE-2010-2097; Only triggerable by malicious script
+033: CVE-2010-2097; Only triggerable by malicious script
+034: CVE-2010-2097; Only triggerable by malicious script
+035: External app not in Debian: e107
+036: CVE-2010-2100; Only triggerable by malicious script
+037: CVE-2010-2100; Only triggerable by malicious script
+038: CVE-2010-2100; Only triggerable by malicious script
+039: CVE-2010-2100; Only triggerable by malicious script
+040: CVE-2010-2100; Only triggerable by malicious script
+041: CVE-2010-2101; Only triggerable by malicious script
+042: CVE-2010-2101; Only triggerable by malicious script
+043: CVE-2010-2101; Only triggerable by malicious script
+044: CVE-2010-2101; Only triggerable by malicious script
+045: CVE-2010-2101; Only triggerable by malicious script
+046: CVE-2010-2101; Only triggerable by malicious script
+047: CVE-2010-2190; Only triggerable by malicious script
+048: CVE-2010-2190; Only triggerable by malicious script
+049: CVE-2010-2191; Only triggerable by malicious script
+050: CVE-2010-2191; Only triggerable by malicious script
+051: CVE-2010-2191; Only triggerable by malicious script
+052: CVE-2010-2191; Only triggerable by malicious script
+053: CVE-2010-2191; Only triggerable by malicious script
+054: CVE-2010-2191; Only triggerable by malicious script
+055: CVE-2010-2191; Only triggerable by malicious script
+056: CVE-2010-3062; Does not affect Lenny; unimportant, mysqlnd not used in
squeeze/sid
+057: CVE-2010-3062; Does not affect Lenny; unimportant, mysqlnd not used in
squeeze/sid
+058: CVE-2010-3063; Does not affect Lenny; unimportant, mysqlnd not used in
squeeze/sid
+059: CVE-2010-3064; Does not affect Lenny; unimportant, mysqlnd not used in
squeeze/sid
+060: CVE-2010-3065; Should be fixed in Lenny and unstable; low importance
+
+

Copied: doc/historic/move_to_l.d.o (from rev 15916, doc/move_to_l.d.o)
==================================================================---
doc/historic/move_to_l.d.o	                        (rev 0)
+++ doc/historic/move_to_l.d.o	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,39 @@
+Hi,
+
+as the effort to offer security support for Debian Testing has become more
+official than it was when it started in 2005, and to make it easier to find
+this announcement list, we have decided to move this list from alioth to
+lists.debian.org. The planned date for the switch is June 25th.
+
+For you this means:
+
+1. Subscribers of the old list will be migrated to the new list automatically.
+
+2. This list, secure-testing-announce at lists.alioth.debian.org will be
renamed
+to debian-testing-security-announce at lists.debian.org. Mails to you will come
+from the new address.
+
+3. The mailinglist headers will change. If you filter for headers, please
+adjust your setup accordingly. The new header will be:
+
+List-Id: <debian-testing-security-announce.lists.debian.org>
+
+4. The subject will no longer contain the prefix [SECURITY].
+
+5. Mails will originate from a different server. If you had any special
+configuration (like an exception from grey-listing) for the old server, change
+this to:
+
+	lists.debian.org a.k.a. liszt.debian.org
+	82.195.75.100
+
+6. For unsubscribe instructions, look at the footer of announcements mails sent
+from the new list.
+
+7. The list archive will move to
+
+	http://lists.debian.org/debian-testing-security-announce/
+
+
+If you experience any problems, don''t hesitate to contact us.
+

Copied: doc/historic/testing-security (from rev 15916, doc/testing-security)
==================================================================---
doc/historic/testing-security	                        (rev 0)
+++ doc/historic/testing-security	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,93 @@
+Providing security updates for Debian''s "testing"
distribution.
+
+
+Goals
+
+The initial goals of the Debian testing security team will be to:
+
+ - Provide timely security updates for testing, with fixes being made
+   available no more than four days after a DSA is released.
+ - Work with maintainers to include security fixes from unstable
+   that do not have DSAs.
+ - Maintain a public database and statistics about the current state of
+   security in testing.
+
+
+Existing infrastructure
+
+The main infrastructure we have that could be useful in preparing testing
+security updates is the testing-proposed-updates queue. Thanks to the recent
+work on the sarge release, t-p-u is functional for all (or almost all)
+arches.
+
+There is also all the work of the security team, with DSAs, relationships
+with upstream security sources, etc.
+
+There is the Debian BTS, which contains some but not all details about
+security holes in Debian. Some security holes are not made public until a
+DSA is released, and some are silently fixed in a new upstream release
+uploaded to unstable. The BTS has some issues with keeping track of which
+bugs apply to testing, though its developers have been working on solving
+this problem for a while.
+
+We plan to take advantage of as much of the existing infrastructure as we
+can, but we recognise that using some of it would require work from others
+(ftp admins, security team, BTS admins), that we cannot require be done. We
+plan to be able to function without needing these project resources, though
+they could probably make the job easier.
+
+
+Proposed infrastructure and processes
+
+
+
+This is how things will work for the first phase of the team''s
activity.
+Once the team is proven to work and there is demand, things can be better
+integrated back into Debian. We hope that eventually our updates will be
+available on security.debian.org the same as stable security updates.
+
+There will be an apt repository for testing security updates, similar to
+security.debian.org. Uploads to this repository will be made only by
+members of the testing security team, will be GPG signed in the usual way,
+and will be accompanied a DTSA (Debian Testing Security Advisory), posted
+to our web site, and to a mailing list.
+
+In the very early stages, this will only include security updates for the
+i386 architecture. Security updates for other architectures will be added
+after we work out an autobuilder system (hopefully by using Debian''s
+existing t-p-u autobuilders). 
+
+There will be an issue tracking system, which will be integrated with the
+Debian BTS, so we can flag bugs as security issues for testing, and keep
+track of when they are fixed in unstable, and in testing.
+
+All security updates will be built against the packages in testing, and
+will be versioned to be an upgrade from the version of the package in
+testing, and also as an upgrade from any unfixed version in unstable. Once
+the security hole is fixed in unstable and reaches testing using normal
+channels, the package can be removed from secure-testing.debian.net.
+
+Unlike security updates to package in stable, we will most often not
+backport fixes to the versions of packages in testing. More often we will
+simply take the fixed package from unstable, recompile it if necessary, and
+qualify it for the testing distribution. This may involve upgrading to new
+upstream releases, and so there''s a chance our updates will introduce
new
+bugs. We feel this is not as bad as unfixed security holes, and as a small
+team with limited manpower, this is a useful shortcut. We will make sure
+that out users realise that using our security updates can expose them to
+upgrade bugs.
+
+
+Team organisation
+
+The team will consist entirely of Debian developers. Unless a member of the
+Debian security team joins the Debian testing security team, none of us
+will have any privileged information about future security announcements.
+So we will not be able to fix problems instantaneously, but we hope to get
+all issues fixed within four days of the DSA, and most issues fixed
+somewhat faster. Any Debian developer who has experience with security
+issues is welcome to join the team.
+
+The current team members:
+	Joey Hess
+	<er, someone else please add your name here>

Copied: doc/historic/tmp.txt (from rev 15916, tmp.txt)
==================================================================---
doc/historic/tmp.txt	                        (rev 0)
+++ doc/historic/tmp.txt	2011-01-18 02:17:49 UTC (rev 15917)
@@ -0,0 +1,104 @@
+- Make sure the issue is tracked in the tracker
+- Criteria for potential DSA: Typically used as root, typically used
+  on multiuser system, non-fringe, real world use case (i.e no debug,
+  no examples)
+- This is the initial batch reported by Dmitry, but there might have
+  been followups? We should check this, I haven''t caught up with
+  mail backlog
+- While some issues might not warrant a DSA for Etch, we should be
+  a little more aggressive on maintainters not following up for
+  Lenny and rather go for removal in such cases
+- Since stable updates can be made by any DD we could also advertise
+  this on debian-devel to find a volunteer if the respective
+  maintainers are too busy
+- I think we only need CVE IDs for issues fixed in a DSA or through
+  a point update, oss-security should be better than a CNA pool since
+  there''s a risk of collisions
+
+
+
+DSA: (Name in brackets if someone prepares a DSA)
+ Binary-package: qemu (0.9.1-5) (CVE-2008-4553) (white)
+
+
+SPU:
+ Binary-package: ibackup (2.27-4.1) (CVE-2008-4475)
+ Binary-package: sympa (5.3.4-5) (CVE-2008-4476)
+ Binary-package: freeradius-dialupadmin (2.0.4+dfsg-4) (CVE-2008-4474)
+ Binary-package: fwbuilder (2.1.19-3) (CVE requested)
+ Binary-package: aegis-web (4.24-3) (CVE requested)
+ Binary-package: rancid-util (2.3.2~a8-1) (CVE requested)
+ Binary-package: fml (4.0.3.dfsg-2) (CVE requested)
+ Binary-package: gdrae (0.1-1) (CVE requested)
+ Binary-package: cdrw-taper (0.4-2)
+ Binary-package: digitaldj (0.7.5-6+b1)
+ Binary-package: xastir (1.9.2-1)
+ Binary-package: aview (1.3.0rc1-8)
+ Binary-package: xcal (4.1-18.3)
+ Binary-package: mgt (2.31-5)
+ Binary-package: sng (1.0.2-5)
+ Binary-package: cdcontrol (1.90-1.1)
+ Binary-package: apertium (3.0.7+1-1+b1)
+ Binary-package: rccp (0.9-2)
+ Binary-package: xmcd (2.6-19.3)
+ Binary-package: xsabre (0.2.4b-23) (CVE-2008-4407)
+ Binary-package: realtimebattle-common (1.0.8-2)
+ Binary-package: cman (2.20080629-1)
+ Binary-package: wims (3.62-13)
+ Binary-package: konwert-filters (1.8-11.1)
+ Binary-package: crossfire-maps (1.11.0-1)
+ Binary-package: sgml2x (1.0.0-11.1)
+ Binary-package: xen-utils-3.2-1 (3.2.1-2)
+ Binary-package: myspell-tools (1:3.1-20)
+ Binary-package: emacs-jabber (0.7.91-1)
+ Binary-package: audiolink (0.05-1)
+ Binary-package: impose+ (0.2-11)
+ Binary-package: emacspeak (26.0-3) (CVE-2008-4191)
+ Binary-package: netmrg (0.20-1)
+ Binary-package: r-base-core (2.7.1-1) (CVE-2008-3931)
+ Binary-package: dist (1:3.5-17-1)
+ Binary-package: gpsdrive-scripts (2.10~pre4-3)
+ Binary-package: rkhunter (1.3.2-3)
+ Binary-package: mgetty-fax (1.1.36-1.2)
+
+Non-issues (not exploitable, only examples or very exotic use cases,
+e.g. only exploitable when debugging a certain option, not present
+in Etch or only exploitable during package build time):
+ Binary-package: ogle-mmx (0.9.2-5.2)
+ Binary-package: ogle (0.9.2-5.2)
+ Binary-package: openoffice.org-common (1:2.4.1-6)
+ Binary-package: postfix (2.5.2-2)
+ Binary-package: tiger (1:3.2.2-3.1)
+ Binary-package: linuxtrade (3.65-8+b4)
+ Binary-package: arb-common (0.0.20071207.1-4)
+ Binary-package: scratchbox2 (1.99.0.24-1)
+ Binary-package: linux-patch-openswan (1:2.4.12+dfsg-1.1)
+ Binary-package: firehol (1.256-4)
+ Binary-package: mafft (6.240-1)
+ Binary-package: liguidsoap (0.3.6-4)
+ Binary-package: ampache (3.4.1-1)
+ Binary-package: scilab-bin (4.1.2-5)
+ Binary-package: bk2site (1:1.1.9-3.1)
+ Binary-package: freevo (1.8.1-0)
+ Binary-package: dpkg-cross (2.3.0)
+ Binary-package: initramfs-tools (0.92f)
+ Binary-package: datafreedom-perl (0.1.7-1)
+ Binary-package: printfilters-ppd (2.13-9)
+ Binary-package: sendmail-base (8.14.3-5)
+ Binary-package: gccxml (0.9.0+cvs20080525-1)
+ Binary-package: aegis (4.24-3)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Deleted: doc/lenny_release
==================================================================---
doc/lenny_release	2011-01-18 02:17:42 UTC (rev 15916)
+++ doc/lenny_release	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,35 +0,0 @@
-Subject: Temporary suspension of testing security support after release of 5.0
(lenny)
-
-Due to the experiences we made after the last stable Debian release, the
-Testing Security Team believes that it will be impossible to provide proper
-security support for the new testing (Debian "squeeze") in the weeks
following
-the release of Debian 5.0 (lenny).  Therefore we will temporarily suspend
-security support for Debian testing after the release.
-
-If you need security support, we strongly recommend that you now change your
apt
-sources.list entries to point to "lenny" instead of
"testing".  This way you
-will automatically stay with "lenny" after its release as stable and
will
-receive the normal security support for Debian stable.  After the begin of
-security support for Debian "squeeze" is announced, you may safely
upgrade to
-testing again.
-
-
-There are two reasons for this suspension:
-
-After a stable release it will take some time to get the security related
buildd
-infrastructure for the new testing in place.  Since many people will be busy
-celebrating the release, we don''t know how long this will take ;-)
-
-In addition to that, we expect that shortly after the release a new libc
-version will be uploaded to unstable, which will block most packages from
-migrating from unstable to testing.  This means that no security fixes will
-reach testing from unstable.  Since the Testing Security Team does not have
-enough members to backport all security fixes to testing, it will be impossible
-to provide proper security support.  After the last stable release (etch) it
-took nearly two months until the new glibc reached testing.
-
-On the other hand, libc blocking most packages from migrating to testing also
-means that the difference between stable and testing will not grow quickly in
-the weeks after lenny release.  Therefore staying with stable should be an
-acceptable solution for most users during that time.  If you absolutely need
-newer packages, you may also consider using unstable instead of testing.

Deleted: doc/move_to_l.d.o
==================================================================---
doc/move_to_l.d.o	2011-01-18 02:17:42 UTC (rev 15916)
+++ doc/move_to_l.d.o	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,39 +0,0 @@
-Hi,
-
-as the effort to offer security support for Debian Testing has become more
-official than it was when it started in 2005, and to make it easier to find
-this announcement list, we have decided to move this list from alioth to
-lists.debian.org. The planned date for the switch is June 25th.
-
-For you this means:
-
-1. Subscribers of the old list will be migrated to the new list automatically.
-
-2. This list, secure-testing-announce at lists.alioth.debian.org will be
renamed
-to debian-testing-security-announce at lists.debian.org. Mails to you will come
-from the new address.
-
-3. The mailinglist headers will change. If you filter for headers, please
-adjust your setup accordingly. The new header will be:
-
-List-Id: <debian-testing-security-announce.lists.debian.org>
-
-4. The subject will no longer contain the prefix [SECURITY].
-
-5. Mails will originate from a different server. If you had any special
-configuration (like an exception from grey-listing) for the old server, change
-this to:
-
-	lists.debian.org a.k.a. liszt.debian.org
-	82.195.75.100
-
-6. For unsubscribe instructions, look at the footer of announcements mails sent
-from the new list.
-
-7. The list archive will move to
-
-	http://lists.debian.org/debian-testing-security-announce/
-
-
-If you experience any problems, don''t hesitate to contact us.
-

Deleted: doc/testing-security
==================================================================---
doc/testing-security	2011-01-18 02:17:42 UTC (rev 15916)
+++ doc/testing-security	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,93 +0,0 @@
-Providing security updates for Debian''s "testing"
distribution.
-
-
-Goals
-
-The initial goals of the Debian testing security team will be to:
-
- - Provide timely security updates for testing, with fixes being made
-   available no more than four days after a DSA is released.
- - Work with maintainers to include security fixes from unstable
-   that do not have DSAs.
- - Maintain a public database and statistics about the current state of
-   security in testing.
-
-
-Existing infrastructure
-
-The main infrastructure we have that could be useful in preparing testing
-security updates is the testing-proposed-updates queue. Thanks to the recent
-work on the sarge release, t-p-u is functional for all (or almost all)
-arches.
-
-There is also all the work of the security team, with DSAs, relationships
-with upstream security sources, etc.
-
-There is the Debian BTS, which contains some but not all details about
-security holes in Debian. Some security holes are not made public until a
-DSA is released, and some are silently fixed in a new upstream release
-uploaded to unstable. The BTS has some issues with keeping track of which
-bugs apply to testing, though its developers have been working on solving
-this problem for a while.
-
-We plan to take advantage of as much of the existing infrastructure as we
-can, but we recognise that using some of it would require work from others
-(ftp admins, security team, BTS admins), that we cannot require be done. We
-plan to be able to function without needing these project resources, though
-they could probably make the job easier.
-
-
-Proposed infrastructure and processes
-
-
-
-This is how things will work for the first phase of the team''s
activity.
-Once the team is proven to work and there is demand, things can be better
-integrated back into Debian. We hope that eventually our updates will be
-available on security.debian.org the same as stable security updates.
-
-There will be an apt repository for testing security updates, similar to
-security.debian.org. Uploads to this repository will be made only by
-members of the testing security team, will be GPG signed in the usual way,
-and will be accompanied a DTSA (Debian Testing Security Advisory), posted
-to our web site, and to a mailing list.
-
-In the very early stages, this will only include security updates for the
-i386 architecture. Security updates for other architectures will be added
-after we work out an autobuilder system (hopefully by using Debian''s
-existing t-p-u autobuilders). 
-
-There will be an issue tracking system, which will be integrated with the
-Debian BTS, so we can flag bugs as security issues for testing, and keep
-track of when they are fixed in unstable, and in testing.
-
-All security updates will be built against the packages in testing, and
-will be versioned to be an upgrade from the version of the package in
-testing, and also as an upgrade from any unfixed version in unstable. Once
-the security hole is fixed in unstable and reaches testing using normal
-channels, the package can be removed from secure-testing.debian.net.
-
-Unlike security updates to package in stable, we will most often not
-backport fixes to the versions of packages in testing. More often we will
-simply take the fixed package from unstable, recompile it if necessary, and
-qualify it for the testing distribution. This may involve upgrading to new
-upstream releases, and so there''s a chance our updates will introduce
new
-bugs. We feel this is not as bad as unfixed security holes, and as a small
-team with limited manpower, this is a useful shortcut. We will make sure
-that out users realise that using our security updates can expose them to
-upgrade bugs.
-
-
-Team organisation
-
-The team will consist entirely of Debian developers. Unless a member of the
-Debian security team joins the Debian testing security team, none of us
-will have any privileged information about future security announcements.
-So we will not be able to fix problems instantaneously, but we hope to get
-all issues fixed within four days of the DSA, and most issues fixed
-somewhat faster. Any Debian developer who has experience with security
-issues is welcome to join the team.
-
-The current team members:
-	Joey Hess
-	<er, someone else please add your name here>

Deleted: tmp.txt
==================================================================--- tmp.txt
2011-01-18 02:17:42 UTC (rev 15916)
+++ tmp.txt	2011-01-18 02:17:49 UTC (rev 15917)
@@ -1,104 +0,0 @@
-- Make sure the issue is tracked in the tracker
-- Criteria for potential DSA: Typically used as root, typically used
-  on multiuser system, non-fringe, real world use case (i.e no debug,
-  no examples)
-- This is the initial batch reported by Dmitry, but there might have
-  been followups? We should check this, I haven''t caught up with
-  mail backlog
-- While some issues might not warrant a DSA for Etch, we should be
-  a little more aggressive on maintainters not following up for
-  Lenny and rather go for removal in such cases
-- Since stable updates can be made by any DD we could also advertise
-  this on debian-devel to find a volunteer if the respective
-  maintainers are too busy
-- I think we only need CVE IDs for issues fixed in a DSA or through
-  a point update, oss-security should be better than a CNA pool since
-  there''s a risk of collisions
-
-
-
-DSA: (Name in brackets if someone prepares a DSA)
- Binary-package: qemu (0.9.1-5) (CVE-2008-4553) (white)
-
-
-SPU:
- Binary-package: ibackup (2.27-4.1) (CVE-2008-4475)
- Binary-package: sympa (5.3.4-5) (CVE-2008-4476)
- Binary-package: freeradius-dialupadmin (2.0.4+dfsg-4) (CVE-2008-4474)
- Binary-package: fwbuilder (2.1.19-3) (CVE requested)
- Binary-package: aegis-web (4.24-3) (CVE requested)
- Binary-package: rancid-util (2.3.2~a8-1) (CVE requested)
- Binary-package: fml (4.0.3.dfsg-2) (CVE requested)
- Binary-package: gdrae (0.1-1) (CVE requested)
- Binary-package: cdrw-taper (0.4-2)
- Binary-package: digitaldj (0.7.5-6+b1)
- Binary-package: xastir (1.9.2-1)
- Binary-package: aview (1.3.0rc1-8)
- Binary-package: xcal (4.1-18.3)
- Binary-package: mgt (2.31-5)
- Binary-package: sng (1.0.2-5)
- Binary-package: cdcontrol (1.90-1.1)
- Binary-package: apertium (3.0.7+1-1+b1)
- Binary-package: rccp (0.9-2)
- Binary-package: xmcd (2.6-19.3)
- Binary-package: xsabre (0.2.4b-23) (CVE-2008-4407)
- Binary-package: realtimebattle-common (1.0.8-2)
- Binary-package: cman (2.20080629-1)
- Binary-package: wims (3.62-13)
- Binary-package: konwert-filters (1.8-11.1)
- Binary-package: crossfire-maps (1.11.0-1)
- Binary-package: sgml2x (1.0.0-11.1)
- Binary-package: xen-utils-3.2-1 (3.2.1-2)
- Binary-package: myspell-tools (1:3.1-20)
- Binary-package: emacs-jabber (0.7.91-1)
- Binary-package: audiolink (0.05-1)
- Binary-package: impose+ (0.2-11)
- Binary-package: emacspeak (26.0-3) (CVE-2008-4191)
- Binary-package: netmrg (0.20-1)
- Binary-package: r-base-core (2.7.1-1) (CVE-2008-3931)
- Binary-package: dist (1:3.5-17-1)
- Binary-package: gpsdrive-scripts (2.10~pre4-3)
- Binary-package: rkhunter (1.3.2-3)
- Binary-package: mgetty-fax (1.1.36-1.2)
-
-Non-issues (not exploitable, only examples or very exotic use cases,
-e.g. only exploitable when debugging a certain option, not present
-in Etch or only exploitable during package build time):
- Binary-package: ogle-mmx (0.9.2-5.2)
- Binary-package: ogle (0.9.2-5.2)
- Binary-package: openoffice.org-common (1:2.4.1-6)
- Binary-package: postfix (2.5.2-2)
- Binary-package: tiger (1:3.2.2-3.1)
- Binary-package: linuxtrade (3.65-8+b4)
- Binary-package: arb-common (0.0.20071207.1-4)
- Binary-package: scratchbox2 (1.99.0.24-1)
- Binary-package: linux-patch-openswan (1:2.4.12+dfsg-1.1)
- Binary-package: firehol (1.256-4)
- Binary-package: mafft (6.240-1)
- Binary-package: liguidsoap (0.3.6-4)
- Binary-package: ampache (3.4.1-1)
- Binary-package: scilab-bin (4.1.2-5)
- Binary-package: bk2site (1:1.1.9-3.1)
- Binary-package: freevo (1.8.1-0)
- Binary-package: dpkg-cross (2.3.0)
- Binary-package: initramfs-tools (0.92f)
- Binary-package: datafreedom-perl (0.1.7-1)
- Binary-package: printfilters-ppd (2.13-9)
- Binary-package: sendmail-base (8.14.3-5)
- Binary-package: gccxml (0.9.0+cvs20080525-1)
- Binary-package: aegis (4.24-3)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-