[Secure-testing-commits] r6911 - doc
micah at alioth.debian.org
micah at alioth.debian.org
Thu Oct 11 21:23:49 UTC 2007
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.
More information about the Secure-testing-commits
mailing list