Hello world,
You should probably read all of this message, or at least skim the first
sentence of each paragraph to make sure you don't miss anything. Oh,
and if it's not the 11th yet where you are, obviously you shouldn't read
this message.
So, presumably everyone who's reading this has already seen the
previous message, which indicated the security infrastructure work we
were waiting on is getting close to done. For those of you who hadn't,
consider yourself updated.
First, I should emphasise that security stuff is *not* yet finished. That
most of the remaining work should be bug fixes and a matter of installing
previously tested software on different machines doesn't mean there's
no work left to be done. We're not going to be releasing in the next
few hours.
We're also not entirely done developing woody. In the previous update,
I indicated that I thought woody was ready to be released. We're now
in the fairly fortunate position of being able to review any problems
that have come up with woody in the month after I made that statement
and see how accurate, or not, it was.
So, the easiest first step in such a review is to see what changes have
actually been made to woody since May 1. They are:
* a new boot-floppies upload (3.0.23-2002-05-21), particularly for
sparc (which couldn't produce bootable CDs with previous b-f
builds), and ia64 (which needed a new kernel version)
* removed packages: (mostly stuff that was requested to be removed
from unstable that isn't depended on by anything in woody)
atm
chess
kernel-image-2.2.20-udma100-ext3-i386 [zlib bug]
kernel-source-2.4.12
kernel-source-2.4.13
libpgsql
libticables2
libticalcs2
linkchecker-ssl
mkinitrd-cd
mmix-src [broken, 145534]
modules-scyld-source-0.0
tom
wmspaceweather [147284]
xshogi
* binary-only updates to packages on particular architectures to bring
them in sync:
cl-imho/ia64
clanbomber/mipsel
clanlib0/mips,mipsel
dossizola/arm
effectv/ia64
eglade/hppa
electricsheep/m68k
fakeroot/mipsel
flightgear/mips,mipsel
ginac/m68k
kernel-patch-2.4.17-mips/mips,mipsel
libqt3-psql/arm
lsh-utils/ia64
lvm-common/arm,hppa,ia64,m68k,mips,s390
mm/hppa
mpqc/m68k
mrproject/arm
muse/arm,hppa
netsaint-plugins/arm
netsaint-plugins/arm
openafs-krb5/ia64
palo/arm
r-base/mips
raidtools/mips
scribe/m68k
star/alpha
* updated packages (source and binaries across all applicable
architectures):
abiword [various minor bugs, update to be > version 1.00]
apache [security issues]
arch [security issues]
base-config [looping problem]
bind9 [9.2.1-1 CERT]
brltty [broken init script]
cweb [145534]
dhcp3 [security, 3.0.1rc9-1 CERT CA-2002-12]
dns-browse [security, 147654]
dpkg [enable force-overwrite by default]
ecartis [security, argv buffer overflow, bugtraq, 147064]
eterm [security, 0.9.2-0pre2002042903 bug# 141374]
ethereal [security, 0.9.4-1 ethereal advisory enpa-sa-00004]
evolution [security, 1.0.3-3 bug# 145903]
gaim [security, 0.57 buffer overflow in TOC protocol plugin]
gal [needed by evolution]
gdk-pixbuf [needed by gaim and evolution]
glibc [nscd security issue]
libnss-lwres [crypto-in-main]
lukemftp [security, 1.5-7 bug# 146148]
lvm10 [new lvm systems]
lvm10 [twice! "downgrade" from 1.1 to 1.0]
mnogosearch [security, 3.1.19-3 bug# 146720]
mutt [crypto-in-main, 145770]
orbit [needed by abiword]
psycopg [crypto-in-main]
qpopper [security, 4.0.4-2 bug# 144974]
rblcheck [145769]
snoopy [147169]
squirrelmail [security, 1:1.2.6-1 bug# 144496]
trafstats [security, 0.4.19-4 bug# 145361]
webmin [security, 0.94-5 buffer overflow 147599]
A few of these are real problems: the problem with the sparc boot-floppies
and dpkg are relatively serious issues for release and weren't discovered,
let alone fixed, until after May. Likewise, the lvm and base-config
problems aren't really things we would have liked to have had to deal
with after commiting to a release. There're also a handful of belated
crypto-in-main related changes, that should've (and in most cases
could've) been accepted into woody before May 1.
Of the remainder, there are four or five packages that've been updated
or removed at the request of the maintainer that we could've lived with
pretty easily as they were, and a whole host of security updates, that
we generally have to live with maintaining post release anyway.
As far as this goes, it seems fairly reasonable so far. Woody is certainly
a long way off perfect, but it seems to be standing up fairly well,
after a month's scrutiny.
So.
From this point on, security updates should be done entirely through the
security team. They (via the new security software) will make uploads both
to security.debian.org and to the appropriate proposed-updates directory.
If you have a security problem in your package, make sure they're informed
about it. They'll give you any further instructions about exactly what
they'd like you to do from there. Security updates processed before
release will be included in the release.
Otherwise, over the next week or so, I'd like to encourage people to
do their own poking around at woody to see if my opinion strikes you
as accurate. Are there any major issues that desperately need to be
addressed before we release?
If you find some, you should do the following:
* Discuss it with some other developers to make sure you're not
freaking out over nothing. We've got 15,000 open bugs that'll all
make some of our users (or some of us) miserable one way or
another, and we simply can't do anything about the vast majority
of them for woody. Is the problem you found particularly special,
or is it just something we need to fix before th enext release?
* Make sure it's fixable. If there's no bug report filed,
file one, and include a full explanation. If there's no patch
in the bug report, work out what the problem is and fix it. If
it hasn't been fixed in unstable yet, contact the maintainer and
make sure it is fixed in unstable. Do an NMU if the maintainer's
not able to fix it.
* Send an email to me pointing to the bug report and making sure it's
clear why this problem needs to be fixed in woody. There's a special
email address for this, viz:
ajt-woody-sucks@debian.org
which should get you a much better response than such mails to
me have been getting over the past month. Be clear, and concise,
but include all the details. You may wish to begin your emails
"Woody sucks because...". Once you've done that, you should get
a reply indicating whether it really is worth fixing, or not.
* If it is worth fixing, you'll then need to prepare a
"backport" to testing. This means preparing a new version of
the package with a different version number (it needs to be a
lower version number than the package in unstable to ensure
upgrades behave sensibly) and uploading it to "testing"
instead of "unstable" (or "frozen" or "woody-proposed-updates").
Presuming we're stay in good shape for a week or so, and can solve any
problems that're found, we'll be looking to release shortly after that.
In the meantime, since we have woody-proposed-updates operational,
and won't be accepting further promotion of packages from unstable to
testing, there's no need to be particularly wary about uploading new
stuff to unstable. So, have at it.
Cheers,
aj (woody release manager)
--
Anthony Towns <ajt@debian.org>
Attachment:
pgppGx0XrghVn.pgp
Description: PGP signature