Re: security in testing
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 tpu@debian.org 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
Reply to: