Re: Debian should not modify the kernels!
On Thursday 25 September 2003 01:44, Matthew Garrett wrote:
> martin f krafft wrote:
> >also sprach Matthew Garrett <mgarrett@chiark.greenend.org.uk>
> > [2003.09.22.1=
> >
> >320 +0200]:
> >> It would be inappropriate to do it within a stable release, sure,
> >> but it is something that Debian do do in general. In this case
> >> it's a chunk of code that has almost nothing to do with the core
> >> kernel code - it just so happens that in the pathological case of
> >> a kernel patch, there's some awkwardness. That's an indication
> >> that our kernel patching system should be rationalised, not that
> >> shipping modified kernels is wrong.
> >
> >First, you should not compare kernel packages to the rest of the
> >Debian system. Second, read again what you wrote. Are you kidding
> >me?
>
> Why not? It's a package. We modify it as we need to in order to provide
> functionality and satisfy the needs of our users. I'm perfectly willing
> to bet that more of our users are interested in a functional ipsec stack
> than are interested in the grsecurity patch.
I think this is not a gamble story to make a bet. I as an debian user am sorry
to hear that from you. This is simply unfair. Do in mind that there is no
sane way to understand if users prefer ipsec or grsec to be included by
default in kernel-source-<version>. Both ipsec (freeswan) and grsec kernel
patches are not security fixes, they do not fix existing security holes, they
are security enhancements. They both deserve to be included as
kernel-patch-<feature> packages... Then users will be informed that as of
2.4.22 these are conflicting patches and will use just one of them on their
demand. Do you really know how many kernel-patches as debian packages are
broken because of they expext to patch the vanilla 2.4.22 tree. Then if those
maintainers try to adjust those unapplyable kernel patches to apply to ipsec
patched debian's kernel tree they will rather introduce new (even security)
bugs than fix the situation. I personally won't trust such sources. The fair
solutions IMHO is to have a clear target to apply external feature patches.
> >"it's a chunk of code that has almost nothing to do with the core
> >kernel code"
I just plain do not trust such explanations about the kernel subsystems.
One bit could be crucial ! But this is not the real issue here, the real one
is that this is just not fair to break other people's work in the name of
testing purposes covered by baseless explanations.
> In that it can be inserted without modifying behaviour of things that
> other parts of the kernel or userland depend upon.
>
> >You don't consider the IP stack to be core? Are you a Windows user?
>
> I'm a Windows user when I'm paid to be, yes. Have you stopped beating
> your wife yet?
Then do not come with laughts like 'my toy is better that yours, so your does
not deserve to exist' ... This is not a real resolution of that issue.
--
pub 4096R/0E4BD0AB 2003-03-18 <keyserver.bu.edu>
1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: