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 <ajt@debian.org>
Attachment:
pgpHx31fc7liA.pgp
Description: PGP signature