[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#771208: unblock: busybox/1:1.22.0-14

(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:


> 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?


Attachment: signature.asc
Description: Digital signature

Reply to: