On Tue, Feb 22, 2005 at 03:09:55PM -0500, Joey Hess wrote: > > > - security response time (more builds to do) > > Which DSAs came out later than they should have because of this > > supposed delay? Nor could this possibly slow release. > DSAs are occasionally delayed waiting on builds. The priveliged nature > of much of the information surrounding DSAs makes it impossible for me > to give a list, but I've seen it happen repeatedly. The most glaring > example in recent memory is the 6 or so months it took for us to get > updated kernels in stable for last spring's set of very bad kernel > security holes. > Security bugs which are currently not fixed in testing, and which either > would be fixed there or would not be a concern if it wasn't for the need > to support all architectures include: Just so we're clear on *which* architectures are at issue here, and why they are: > bidwatcher 1.3.17-1 needed, have 1.3.16-1 for DSA-687-1 arm, sparc builds waiting on the xfree86 chroot cleanup > bind 1:8.4.6-1 needed, have 1:8.4.4-1 for CAN-2005-0033 arm waits on cleanup of yacc alternative mess in buildd chroot > emacs21 21.3+1-9 needed, have 21.3+1-8 for CAN-2005-0100, DSA-685-1 m68k, mips builds missing due to a timestamp skew problem in the package that constitutes a sourceful bug in emacs21 which affects slow architectures *and all archs running 2.6 kernels* (hence amd64 fails, and after release any buildds that switch to 2.6 kernels in sarge would fail) > kdeedu 4:3.3.2-2 needed, have 4:3.3.1-3 for CAN-2005-0011 mips, mipsel build of quantlib needed, requires adjusting buildd timeouts > kdelibs 4:3.3.2-2 needed, have 4:3.3.2-1 for CAN-2005-0365 not actually an architecture stall problem anymore; this was a missing mipsel build, but now it's that kdelibs is hung up waiting for aspell, which is the sort of bad timing that can affect us at any moment (but is certainly more likely when uploads to unstable for all archs are spread across a longer period) > kernel-image-2.4.27-alpha (unfixed; bug #280492) for CAN-2003-0465 alpha, obviously > kernel-image-2.4.27-sparc 2.4.27-2 needed, have 2.4.27-1 for CAN-2004-1056, CAN-2004-1235 and sparc, of course > kernel-patch-powerpc-2.4.27 (unfixed) for CAN-2004-1056, CAN-2004-1235 powerpc... > xemacs21 21.4.16-2 needed, have 21.4.16-1 for CAN-2005-0100, DSA-671-1 since resolved > xview 3.2p1.4-19 needed, have 3.2p1.4-16 for DSA-672-1 not actually an arch buildd problem, the issue here is that we have known-broken binaries on one arch that need to be removed from the archive; but if we count it, it counts for ia64. So supposing we had some sort of requirement for release archs such as "within 10 days of any source upload, there must be either a binary upload or a FTBFS report for the build", we would presently have to kick out alpha amd64 arm ia64 m68k mips mipsel powerpc sparc and keep hppa i386 s390; and if we relax this to only require "within 10 days of any source upload, assuming the source isn't buggy, there must be a binary upload for this security bug", we would be kicking out alpha arm mips mipsel powerpc sparc and keeping amd64 hppa ia64 i386 m68k s390, which I hope amply demonstrates the point to people that railing against slow or unpopular architectures is not actually going to bring about the desired outcome. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature