(Putting on my d-i RM fedora.) Michael Tokarev <mjt@tls.msk.ru> (2014-11-27): > Please unblock package busybox. Last upload has one security bugfix > (CVE-2014-4607, #768945), the fix is from upstream stable branch, > fixing an integer overflow in lzo decompressor; it adds a Built-Using > control field for busybox-static variant (#768926), and also arranges > build system to only produce binary or indep .debs (or both), depending > on the d/rules target (binary-all vs binary-indep vs binary) -- this > is a long-standing lintian bug which I overlooked previously. #768926 is still not #768876: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768926#28 > The busybox-static fix turned out to be a fun case, because I needed > a way to build-conflict on a non-broken libc (because the original > prob is in libc due to #754813), and that turned out to be a not-so- > trivial task, which resulted in several iterations. Meanwhile I > discovered that current glibc is not able to produce working stati- > cally linked executables on hurd which uses nss functions -- > statically linked executable on hurd just segfaults. So now, > after a fix for #768926, busybox package does not build on hurd, > while previously it silently produced failing busybox-static. > Hurd people are working on the fix. > > (The Built-Using field generation is a bit fun here: I asked on IRC > how people identify which libc is in use, and got various somewhat- > incpmplete replies (the prob is that on different arches, libc package > is named differently). So I invented my own way for busybox, because > this package allows me to do that -- I took the contents of $shlibs:Depends > variable for the dynamically-linked version, and transformed it into > a list of sources required for Built-Using using dpkg-query.) > > There's no code changes except the lzo decompression bugfix, only > packaging changes. > > Since busybox is used in d-i too, I kindly request for a > udeb-unblock too. > > Previously I submitted an unblock request for busybox 1.22.0-10, > as #769129, but that turned out to be a bit preliminary because > of the fun with libc versioned build dependency iterations. #768876 is tagged jessie-ignore so I'm really unconvinced by the debian/rules changes. At this stage, I'd rather see the security fix only. Release team people, what's your take on this? Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature