[Secure-testing-commits] r6905 - doc

Thu Oct 11 03:49:29 UTC 2007

Author: micah
Date: 2007-10-11 03:49:29 +0000 (Thu, 11 Oct 2007)
New Revision: 6905

Modified:
   doc/bits_2007_10_x
Log:
I've made some changes to the bits, mostly a few grammatical tweaks, 
changed Testing Security Team to just 'team', made paragraphs have
more spaces, and added some sentences to try to make it flow better.


Modified: doc/bits_2007_10_x
===================================================================

--- doc/bits_2007_10_x	2007-10-10 23:35:36 UTC (rev 6904)
+++ doc/bits_2007_10_x	2007-10-11 03:49:29 UTC (rev 6905)
@@ -1,7 +1,8 @@
-Hi fellow developers
+Hi fellow developers,
 
-We finally got around to issue this email and inform you about the
+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 ask one of the
 individual members of the team. A full member list can be found on
@@ -11,78 +12,95 @@
 New task of the testing-security team
 -------------------------------------
 
-In the past, the Testing Security Team was concerned to bring all
-changes done by DSAs into unstable and testing. It also worked on
-merging all the old DSA patches from woody and sarge into unstable and
-testing. We are pleased to announce that this work is more or less
-done. Now the team concentrates on the full security support for
-testing (and in a matter of speaking also for unstable).
+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
+also worked on merging all the old DSA patches from woody and sarge
+into unstable and testing. We are pleased to announce that this work
+is more or less complete. Now the team is concentrating on improving
+the full security support for testing (and in a matter of speaking
+also for unstable).
 
 
 New announcement mails
 ----------------------
 
-Because of the fact that most of the security fixes migrate from unstable
-to testing, we felt the need of changing our security announcements.
-Therefore, we set up daily announcements going to the announcement
-mailinglist[0], which include all new security fixes for the testing
-distribution. Most commonly the email shows the migrated packages.
-If there has been a DTSA(Debian Testing Security Advisory) 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 offered in our opinion. In this case, the email will inform
-about such a case as well.
+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
+unstable to testing, this results in very little visibility of the
+work that our team does. We felt that a 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
+mechanism for getting security packages into testing.
 
+Therefore, we set up daily announcements (delivered to the
+announcement mailinglist[0]), 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 offered in our opinion. In this case, the email will
+additionally include information about this a case as well.
+
+
+
 Efforts to fix security issues in unstable
 ------------------------------------------
 
-The Testing Security Team works mainly on the issued 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 such a CVE id, 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 priority to high. The tracker used
-by both, Testing and Stable Security Team, can be found on this
-webpage[1].
-The main task of the Testing Security team is to review the CVE ids,
-informing the Debian maintainers by filling bugs to the BTS, if not
-already done and tracking the security fix down to 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[2].
+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 priority to high. The
+tracker used by both the Testing and Stable Security teams, can be
+found on this webpage[1].
 
+The main task of the Testing Security team is to review CVE id
+relevance to Debian, informing Debian maintainers by filling 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[2].
 
 
+
 Efforts to fix security issues in testing
 -----------------------------------------
 
-As already mentioned, the main effort to keep testing secure is by
-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 to issue a DTSA. We always appreciate, if a
+As already mentioned, the main efforts involved in keeping testing
+secure is by 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, 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
+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 the maintainer
-effort is much preferred.
+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].
 
@@ -104,12 +122,15 @@
 Nico Golde (nion) and Steffen Joeris (white) have been added as new
 members of the Testing Security Team.
 
+If you are interested in joining the team, we always need more people,
+and its not very hard to contribute in very small ways that have large
+impacts! Contact us if you are interested.
 
 So far so good. We hope to keep you updated on testing security issues
 more regularly.
 
-Your
-Testing Security Team
+Yours,
+Testing Security team
 
 
 [0]: http://lists.alioth.debian.org/mailman/listinfo/secure-testing-announce


