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

Re: grsecurity bugs



In-Reply-To=<[🔎] E1A12az-0000dQ-00@gondolin.me.apana.org.au>&Subject=Re:%20Re: Debian should not modify the kernels!

On Sun, 21 Sep 2003, martin f krafft wrote:
> I have uploaded a new version of grsecurity. However, it won't support
> Debian kernels 2.4.20 and up. README.2.4.2x in the package will tell you
> why. In addition:
> 
>   http://lists.debian.org/debian-devel/2003/debian-devel-200309/msg01133.html
> 
> I am sorry if this inconveniences you. I don't have a choice, not only
> because I can't afford to put more time into this, but also because I am not
> going to remove functionality from grsecurity, which would be required to
> cater for the Debian kernels.
> 
> Please complain to the kernel maintainer(s) if you don't like this.
> Or just use a vanilla kernel source tree.
X----

On Sun, 21 Sep 2003 21:41:41 Herbert Xu wrote:

> martin f krafft <madduck@debian.org> wrote:
> > 
> > I am the kernel-patch-2.4-grsecurity maintainer, and I have been
> > flooded with grave and important bugs ever since kernel version
> > 2.4.20, since grsecurity does not apply to these kernel versions
> > anymore. It doesn't apply to the Debianised versions of these
> > kernels anymore, it applies to the vanilla kernel just fine.
>
> I've got a few points for you:
> 
> * The vanilla kernel source is readily available:
>
> apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
> tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
> cd kernel-source-2.4.22
> /usr/src/kernel-patches/all/2.4.22/unpatch/debian

Stop the sarcasm, Herbert!  That is NOT the vanilla kernel!  

What's the friggin point of downloading a Debian kernel-source package (mostly
because we need the convenience of a make-kpkg ready tarball), only to end up
unpatching everything Debian has put it right away?  I might as well download
the upstream tarball from kernel.org myself and then make my own debian/ folder!
Then again, that would disqualify the whole point of having Debian kernel-source
packages.  Now, _that_ is really smart.  Not.


> * The IPSEC backport can be easily reversed by unapplying
> the patches given in the README.Debian file.
>
> * The IPSEC backport has minimal effect on the binary images.  It
> has no effect unless you load the relevant modules.  The increase
> in size is tiny compared to the increases brought on by ACPI and
> compiler changes.  
>
> So either get the people who're complaining to you to unapply the
> IPSEC patch, or fix your patch instead.

The whole point of having a stable branch (currently 2.4) is to guarantee that
people can have a _reliable_ kernel that they can trust will:

1) Behave in a predictable way that is consistant with previous releases from
the same branch (currently 2.4).

2) Remain consistant in terms of features and modus operandi, only bringing in
bugfixes between releases.

3) Can easily receive the most popular patches designed to apply to that branch.

4) When using Debian, that the said patch will apply as easily as downloading
the corresponding kernel-source-<version> and kernel-patch-<version>-foobar,
then running make-kpkg.

Herbert, What you are doing by backporting stuff from kernel 2.6, well beyond
the occasional backporting work that happens on the upstream vanilla kernel 2.4
branch, is _wrong_, because it breaks all 4 points and because it turns the job
of packaging well-known kernel patches into a full recoding chore, instead of
the simple Debian packaging job it ought to be.

Stop it. 

If you really want to have kernel 2.6 features, then go ahead and use that
kernel release and please have the decency of passing on the kernel-2.4
maintenance to someone else, right away.

-- 
Martin-Éric Racine
http://www.pp.fishpool.fi/~q-funk/




Reply to: