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