Hello world, As most of you will have noticed by now, ISS and Theo de Raadt have been kind enough to provide some stress tests for the new security infrastructure we deployed last month. The outcome seems to be that there're a few bugs and a few misfeatures that we'll need to fix, but that it's nevertheless entirely adequate for its primary purpose. Updates for the following packages in woody have been made with the new security system:
apache fetchmail mozilla
apache-perl fetchmail-ssl nn
apache-ssl galeon openssh
bind libapache-mod-perl openssh-krb5
bind9 libapache-mod-python popa3d
bugzilla libapache-mod-ssl squid
courier mailman xchat
[0]
As far as the -woody-sucks email went, there were a number of relatively
minor issues raised. It's resulted in about 17 packages being updated
in woody so far, with a few more still due to be updated, and a few
others that will only be dealt with in a point release. From an overall
perspective, none of the issues are terribly serious, and none of them
are showstoppers.
Right now you're probably checking to see where the dists/stable symlink
points, and asking yourself "if those aren't the showstoppers, what
is?" Well, maybe you weren't, but I did, and here are my answers:
(1) There's still a sizable backlog of security problems that need
fixing. Packages with bugs in the BTS include:
chdrv 138062
nocc 147213
slashem 147120
nethack 147166
ktalkd 147762
sharutils 149454
courier-ssl 149928
There're about eleven more in addition to those. The security team
are working through them, so hopefully we'll have the known security
bugs in woody down to zero or thereabouts fairly soon.
(2) Nobody's yet organised a Debian mini-conference for linux.conf.au
2003 in Perth. (*gasp*!) It's relatively easy to do since most of
the work (organising the venue, accomodation, registrations etc) has
already been done as part of linux.conf.au proper, so all you need
to do is setup a web page and pester people into giving interesting
talks. So, ask not what your woody can do for you, and contact the
organising committee now!
And that's pretty much it. Once those two issues are dealt with, we'll
be going through (roughly) the following process:
a) finalise the contents of woody (include any security updates
that haven't made it in, any last minute -woody-sucks things,
update basedebs.tgz, etc)
b) prepare CD images
c) make the appropriate archive changes to make woody and
woody-proposed-updates be treated as stable/proposed-updates
instead of potato, create a new testing suite, etc...
d) pulse the mirrors, send out announcements
e) make another bold guess at woody's release date, and hope that
for once I'm not too far off
f) flame^H^H^H^H^Hpolitely discuss how we should handle the
next release cycle, and what's the point of stable, and who
should use testing, and so on
Note that you probably won't see any official word until (d).
If you want to prepare a little for (f), you might want to think about
the issues raised in:
http://bad.debian.net/list/2002-May/001887.html [and followups]
and http://www.debianplanet.com/article.php?sid=721&mode=thread&order=0
You might also want to think about things like:
* What could we do to make "testing" more useful?
* Why would anyone run "stable" instead of "testing"? Is there
anything we can change to allow people like that to run
"testing"? (Iterate, end up with a list of neat features to
work out how to support for "testing", and a bunch of things
that people actually find useful that make it worth going
through this much agony every year or so)
Cheers,
aj (woody release manager)
[0] Some random technical details. For developers: since the security
archive is handled in parallel to the main archive, "madison"
doesn't work on it, and you need to use "sec_madison" instead. It's
in /usr/local/bin on satie. Uploads to security, by and large, are
making there way across to the appropriate proposed-updates suite on
auric or pandora, however in some cases the new versioning checks are
causing problems: newer versions have to be _installed_ into unstable
before the security update can be _accepted_ for testing or stable.
There also seems to be some annoying problems with the queueds that
move the uploads from one host to another as necessary, related to
RSA keys.
--
Anthony Towns <[EMAIL PROTECTED]>
pgpRKAvYXDJOp.pgp
Description: PGP signature
