Author: micah Date: 2007-10-11 21:23:49 +0000 (Thu, 11 Oct 2007) New Revision: 6911 Modified: doc/bits_2007_10_x Log: a few more updates/changes Modified: doc/bits_2007_10_x ==================================================================--- doc/bits_2007_10_x 2007-10-11 21:14:06 UTC (rev 6910) +++ doc/bits_2007_10_x 2007-10-11 21:23:49 UTC (rev 6911) @@ -1,16 +1,16 @@ 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. +current state of the Testing Security team and its work. -If you at any stage have questions about the Testing Security Team, +If you at any stage have questions about the Testing Security team, please feel free to come to #debian-security on OFTC or ask one of the individual members of the team. A full member list can be found on http://www.debian.org/intro/organization. -New task of the testing-security team -------------------------------------- +New team goals +-------------- In the past, the Testing Security team concerned itself with the task of bringing all the changes done by DSAs into unstable and testing. It @@ -25,17 +25,17 @@ ---------------------- Because of the fact that most of the work that we do to move along -security fixes ends up in the packages automatically migrating from +security fixes ends up in the packages that automatically migrate from unstable to testing, this results in very little visibility of the work that our team does. We felt that a good way to fix this was by changing our security announcements. -Previously we were following the method that Stable security updates -use by creating DTSA (Debian Testing Security Advisories) only 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. However, this resulted in -very infrequent DTSAs because it was much easier to circumvent this +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 it was much easier to circumvent this mechanism for getting security packages into testing. Therefore, we set up daily announcements (delivered to the @@ -90,16 +90,16 @@ 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, if a -maintainer contacts us about their specific security problem. In this -case, we can assist by telling him 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[3]. 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. +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[3]. 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[4]. @@ -110,10 +110,12 @@ -------------------- There are a number of packages including source code from external -libraries like for example poppler is included in xpdf, kpdf and others. +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[5] of embedded code copies in Debian. -Please contact us for any missing items you know about. +we maintain a list[5] 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.