On Fri, May 16, 2003 at 02:44:28PM +0200, Michael Banck wrote: > On Fri, May 16, 2003 at 01:13:05PM +0200, Sven Luther wrote: > > The only thing really needed here is the RM's blessing, and an > > announcement. > > I have no idea how you might think this announcement should look like. > Could you perhaps at least give a rough outline of it?
What about : We currently don't support secutiry updates (by the security team) for testing or unstable. Security updates for unstable are the responsability of the individual maintainers, which can and should upload fixed packages to close the security holes. Normally such packages would move into testing after they are built for each architectures and the testing-delay is expired (priority of security fix upload should be set to high when uploading to unstable), but sometime dependency problems can stop such fixed packages to be moved into testing in a timely manner (this may even take weeks or month). Since it is unacceptable for debian to distribute packages with known security holes, maintainers should, in case a package cannot enter testing trough the normal means, do a testing-proposed-update. To upload a package to testing proposed update, a package needs to be built in a testing box/chroot/pbuilder, and uploaded to testing-proposed-update, with urgency high. The version number of said package should be the same as the one currently in testing, with a minor bump of the debian version number (1.2.3-4 becomes 1.2.3-4.1). Note : maybe something like 1.2.3-4.0.tpu.1 would be better, -4.1 is already a NMU or something such. Such a package should be as close to possible to the version actually in testing, and not depend on packages and/or versions that are not yet in testing. Note : maybe it is acceptable to use also packages in testing-proposed-updates, but this could cause dependency problems, and is best to be avoided. Also, it is not sure if the buildd will fetch packages out of testing-proposed-updates or not. Notice that the packages can only move from testing-proposed-updates into testing if they fullfill the same criteria as for moving from unstable to testing, and either the RM or one of his assistants gives the green light. So, each time such an upload is made, a email should be sent to the [EMAIL PROTECTED] giving the reasons for the upload. Please notice that this is not a way of circumventing the unstable to testing migration, and uther care should be taken not to break testing more with the fix than it was before. Also, maintainer doing such uploads should follow the buildd logs and check that their packages builds and enters testing correctly, and remedy to any problems that would arise in a timely fashion. Or something of the kind, naturally written by someone who writes better english than me. Also, we could add 2 things, first the RM assitants, which are debian developers who have voluntereed to help the RM in this, and have the right to give the green light to uploads. Second, what could be done about NMUs. Maybe a small group of apprentice security team members could scan the security announcements, and prepare NMU of such security holed packages, in close contact with the maintainer and the RM or his assistants, or maybe even the security team, especially if the problems are also present in stable packages. Additionnaly, they would be the ideal candidate to be promoted to work on the real security team, once they have proven their worth. So, with such an announcement, everyone wins, our user will get a more secure testing, the maintainer will be able to fix things in testing more easily, and the security team would get group of people to draw future team members if needed. The only one who stands to loose is the RM, since he has to green light every upload, but then, with the addition of one or two RM assistants, this may not be such a load after all. Friendly, Sven Luther
