[Debian] Re: Please accept to etch

[Ola Lundqvist]

Hi Steve

On Wed, Mar 14, 2007 at 03:04:24AM -0700, Steve Langasek wrote:
> On Wed, Mar 14, 2007 at 07:12:42AM +0100, Ola Lundqvist wrote:
> > I have a couple of pacakges that I want to be part of etch:
> 
> > * harden (version in unstable now)
> >   Translation updates
> 
> Accepted.

Thanks.

> > * kernel-patch-openvz (version in unstable now)
> >   [SECURITY]: Deadlock in mincore (CVE-2006-4814)
> >   and a number of other critical fixes
> 
> This CVE refers to a kernel bug in Linux 2.4, how does that apply here?

I can see that the CVE refer to 2.4 only but from the URL below
it seems to affect 2.6 as well, at least with openvz enabled.

> What other "critical fixes" does this include?

Here are the most important ones:

Various oops in schedule fixed (OpenVZ bug #412)
http://tinyurl.com/2nh4rv

[SIMFS] Fix statfs behaviour over reiserfs and no-quota case
http://tinyurl.com/38l9t2

[SECURITY]: Deadlock in mincore (CVE-2006-4814)
http://tinyurl.com/34x3p5

[BC] Fix race in IO accounting
http://tinyurl.com/32mbek

[CPT] fix oops in error path
http://tinyurl.com/2pvcp9

[VENET] Fix of ip6 addr add
http://tinyurl.com/3b2t2p

IPv[46] indev initialization fix
Correct inet device initialization order to avoid partly initialized device.
http://tinyurl.com/2oaxlf

Logical refcount loop in ipc ns -> massive leakage
http://tinyurl.com/383dcy

[CPT][IA64] pause() could hang forever
http://tinyurl.com/3b6hel

> At 248kloc, this is far from being a targetted security fix.

Yes I know. The reason why I propose to update it is that the
version currently in testing is a bit "shaky" and the proposed version
is much more stable. At least that it is so from my testing and also
from the testing upstream.

It also look bigger than it is because I had to regenerate the patch
against the source tree.

The kernel patch do not affect any other package, so I can not see that
accepting this package will block anything else. The most it can do
is to create a RC bug on itself. On the other hand it is more likely
that we get RC bugs on the current version in testing, than on this
more stable version (028.18).

I have built the kernel on all supported architectures and done the
same kind of target testing as have been done on all other versions.
stop, start, heavy io etc.

> > * ntop
> >   This has actually been unfrozen, but it has some dependency
> >   issue with libgd2. Will it help if I upload this one to
> >   etch-proposed-updates?
> 
> I don't think it's advisable at this point for us to accept further non-RC
> updates through t-p-u, sorry.

Ok, no problem.

> > * util-vserver
> >   A number of corrections and needed if someone uses the
> >   2.6.19 kernel in the future.
> 
> I believe this is already unblocked.

Ohh, was not aware of that. Sorry for the noise.

Best regards,

// Ola

> -- 
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> vorlon at debian.org                                   http://www.debian.org/
> 

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ----
/  ola at opalsys.net                   Annebergsslingan 37        \
|  opal at debian.org                   654 65 KARLSTAD            |
|  http://opalsys.net/               Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---------------------------------------------------------------