[Secure-testing-commits] r6911 - doc

[micah at alioth.debian.org]

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.