create a historic document dir and move a bunch of outdated stuff there

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

13 files changed, 1287 insertions, 0 deletions

diff --git a/doc/historic/README b/doc/historic/README
new file mode 100644
index 0000000000..fab6bc2d1d
--- /dev/null
+++ b/doc/historic/README
@@ -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.
diff --git a/doc/historic/TODO b/doc/historic/TODO
new file mode 100644
index 0000000000..4809fcd950
--- /dev/null
+++ b/doc/historic/TODO
@@ -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
+
+
diff --git a/doc/historic/announce b/doc/historic/announce
new file mode 100644
index 0000000000..e9168207de
--- /dev/null
+++ b/doc/historic/announce
@@ -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@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
+
diff --git a/doc/historic/announce.2 b/doc/historic/announce.2
new file mode 100644
index 0000000000..d1f1caee4c
--- /dev/null
+++ b/doc/historic/announce.2
@@ -0,0 +1,127 @@
+Subject: announcing the beginning of security support for testing
+
+---------------------------------------------------------------------------
+Debian Testing Security Team                            September 9th, 2005
+secure-testing-team@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@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-----
diff --git a/doc/historic/announce.3 b/doc/historic/announce.3
new file mode 100644
index 0000000000..008d91911d
--- /dev/null
+++ b/doc/historic/announce.3
@@ -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@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@lists.alioth.debian.org.
+
+For more information about the testing security team, see our web site.
+<http://testing-security.debian.net/>.
diff --git a/doc/historic/bits_2007_10_x b/doc/historic/bits_2007_10_x
new file mode 100644
index 0000000000..1162bb73a9
--- /dev/null
+++ b/doc/historic/bits_2007_10_x
@@ -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@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
diff --git a/doc/historic/bits_2008_06_x b/doc/historic/bits_2008_06_x
new file mode 100644
index 0000000000..2193f00478
--- /dev/null
+++ b/doc/historic/bits_2008_06_x
@@ -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@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@lists.alioth.debian.org
+[3]: http://testing-security.debian.net/uploading.html
+[4]: team@security.debian.org
+[5]: http://svn.debian.org/wsvn/secure-testing/data/NMU/list?op=file&rev=0&sc=0
+[6]: team@testing-security.debian.net
+[7]: http://lists.debian.org/debian-devel-announce/2008/03/msg00007.html
diff --git a/doc/historic/lenny_release b/doc/historic/lenny_release
new file mode 100644
index 0000000000..554cd81dee
--- /dev/null
+++ b/doc/historic/lenny_release
@@ -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.
diff --git a/doc/historic/mopb.txt b/doc/historic/mopb.txt
new file mode 100644
index 0000000000..4b00d76e42
--- /dev/null
+++ b/doc/historic/mopb.txt
@@ -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.
+
diff --git a/doc/historic/mops.txt b/doc/historic/mops.txt
new file mode 100644
index 0000000000..63dafa4c45
--- /dev/null
+++ b/doc/historic/mops.txt
@@ -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
+
+
diff --git a/doc/historic/move_to_l.d.o b/doc/historic/move_to_l.d.o
new file mode 100644
index 0000000000..f62c7fdaf6
--- /dev/null
+++ b/doc/historic/move_to_l.d.o
@@ -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@lists.alioth.debian.org will be renamed
+to debian-testing-security-announce@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.
+
diff --git a/doc/historic/testing-security b/doc/historic/testing-security
new file mode 100644
index 0000000000..845636e94d
--- /dev/null
+++ b/doc/historic/testing-security
@@ -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>
diff --git a/doc/historic/tmp.txt b/doc/historic/tmp.txt
new file mode 100644
index 0000000000..ab0f025ade
--- /dev/null
+++ b/doc/historic/tmp.txt
@@ -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)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+