From 38f772f944cd74e3600ed4a6eb178feec8e87b3f Mon Sep 17 00:00:00 2001 From: Michael Gilbert Date: Tue, 18 Jan 2011 02:17:49 +0000 Subject: 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 --- doc/historic/README | 55 ++++++++++ doc/historic/TODO | 50 +++++++++ doc/historic/announce | 133 ++++++++++++++++++++++++ doc/historic/announce.2 | 127 ++++++++++++++++++++++ doc/historic/announce.3 | 46 ++++++++ doc/historic/bits_2007_10_x | 158 ++++++++++++++++++++++++++++ doc/historic/bits_2008_06_x | 146 ++++++++++++++++++++++++++ doc/historic/lenny_release | 35 +++++++ doc/historic/mopb.txt | 237 ++++++++++++++++++++++++++++++++++++++++++ doc/historic/mops.txt | 64 ++++++++++++ doc/historic/move_to_l.d.o | 39 +++++++ doc/historic/testing-security | 93 +++++++++++++++++ doc/historic/tmp.txt | 104 ++++++++++++++++++ 13 files changed, 1287 insertions(+) create mode 100644 doc/historic/README create mode 100644 doc/historic/TODO create mode 100644 doc/historic/announce create mode 100644 doc/historic/announce.2 create mode 100644 doc/historic/announce.3 create mode 100644 doc/historic/bits_2007_10_x create mode 100644 doc/historic/bits_2008_06_x create mode 100644 doc/historic/lenny_release create mode 100644 doc/historic/mopb.txt create mode 100644 doc/historic/mops.txt create mode 100644 doc/historic/move_to_l.d.o create mode 100644 doc/historic/testing-security create mode 100644 doc/historic/tmp.txt (limited to 'doc/historic') 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 "" as the version. If the problem doesn't affect Debian, + use "" 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 "" 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. + + +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. +. + +---------------------------------------------------------------------------- + +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. + + +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. +. 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: + +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 + 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) + + + + + + + + + + + + + + + -- cgit v1.2.3