Re: Debian should not modify the kernels!
On Fri, Oct 10, 2003 at 09:30:06PM +0200, martin f krafft wrote: also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.10.10.0223 +0200]: ...and the freeswan patch is not in the Linux kernel (and as I understand it, it never will be). The IPsec patch is not in the 2.4 kernel either. I don't get your point. It is in 2.5 and 2.6. It is in Linux henceforth. FreeSWAN, on top of its other issues, is not, has never been, and never will be, part of the official kernel. Is that clearer? -- - mdz
Re: Debian should not modify the kernels!
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.10.10.2333 +0200]: It is in 2.5 and 2.6. It is in Linux henceforth. FreeSWAN, on top of its other issues, is not, has never been, and never will be, part of the official kernel. Is that clearer? Doesn't explain why the IPsec patch should be distributed in 2.4 by default. Come on, you just don't want to get my point... -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpbplRaTIGPR.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Thu, Oct 16, 2003 at 07:04:27PM +0200, martin f krafft wrote: also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.10.10.2333 +0200]: It is in 2.5 and 2.6. It is in Linux henceforth. FreeSWAN, on top of its other issues, is not, has never been, and never will be, part of the official kernel. Is that clearer? Doesn't explain why the IPsec patch should be distributed in 2.4 by default. Come on, you just don't want to get my point... It is the difference between a backport of a useful feature from a later release, and an unofficial patch which was rejected upstream. I think I understand fine. -- - mdz
Re: Debian should not modify the kernels!
On Sun, Oct 05, 2003 at 03:18:53PM +0200, Tollef Fog Heen wrote: * Herbert Xu | Very few people really need cramfs if they're building custom kernels. | This is because initrd only makes sense when you're building for a | large number of machines. If you're building a custom kernel, just | compile in all the drivers you need for mounting root and that's that. Except if you want to use EVMS or similar on /, in which case you need the evms userspace tools on the initrd. (Using 2.6, that is, in 2.4 the discovery is done in kernel-space.) Minor correction: with EVMS 1.x (on Linux 2.4), discovery is done in kernel-space. With EVMS 2.x (on Linux 2.4+device-mapper or Linux 2.6), discovery is done in user-space. EVMS 1.x does not support Linux 2.6, but EVMS 2.x does support Linux 2.4. -- - mdz
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 10:20:57PM +0200, martin f krafft wrote: also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.09.29.0232 +0200]: Hear, hear. IPsec in particular is long overdue in the Linux kernel and I am glad to see it. It has existed in the freeswan patch for a while! ...and the freeswan patch is not in the Linux kernel (and as I understand it, it never will be). -- - mdz
Re: Debian should not modify the kernels!
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.10.10.0223 +0200]: ...and the freeswan patch is not in the Linux kernel (and as I understand it, it never will be). The IPsec patch is not in the 2.4 kernel either. I don't get your point. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpZ9fkUQ4Sgr.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Tuesday, Oct 7, 2003, at 15:07 US/Eastern, martin f krafft wrote: Alright, I give you that. But it works. Sort of. I routinely have to fight it on my IPSec gateway. It really doesn't like some of the things I do with (to?) it. I understand the new IPSec stack is supposed to be much better and plan on installing it ASAP.
Re: Debian should not modify the kernels!
On Mon, 6 Oct 2003, martin f krafft wrote: also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.28.0510 +0200]: For example, the grsecurity patch has had a history of conflicts with various patches in the Debian kernel source. Most of those patches that caused conflicts were in fact essential security fixes. You can review this for yourself by visiting to the BTS entry for the grsecurity package. If it's a small security fix, then I am willing to work that into grsecurity. But I won't port grsecurity to a new IP stack nor the other way around. So, there will be no grsecurity for 2.6? 1KB /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped)
Re: Debian should not modify the kernels!
also sprach Adam Borowski [EMAIL PROTECTED] [2003.10.08.1124 +0200]: If it's a small security fix, then I am willing to work that into grsecurity. But I won't port grsecurity to a new IP stack nor the other way around. So, there will be no grsecurity for 2.6? There will be, but not ported by me. The grsecurity team is porting it, but do not expect an official release before 2.6 is final. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpCYPeKKs9Mr.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, 2003-10-06 at 21:19, martin f krafft wrote: I'd appreciate if you kept your opinions to yourself, Can you do the same? Scott (Unsigned as I've already packed my keyring for Linux Expo today) -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Re: Debian should not modify the kernels!
also sprach Steve Langasek [EMAIL PROTECTED] [2003.10.07.0104 +0200]: As stated above, this is not a reasonable restriction. An arbitrary kernel patch package might conflict with *any* changes made to the kernel-source package, including simple security fixes. A simple fix is easier to work around than a new IP stack. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpjPGgp02UKl.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, 2003-10-06 at 15:39, martin f krafft wrote:
also sprach Eduard Bloch [EMAIL PROTECTED] [2003.09.22.1207 +0200]:
Let's create a package called linux-2.4.22 or
linux-2.4.22-pure-vanilla-source-for-you-to-patch with a script which
does exactly this.
I oppose. Let's get rid of kernel-{source,image,etc.} and provide
linux-kernel-*. Then provide kernel-patch-debian and
kernel-patch-ipsec as separate packages!
A-Freaking-MEN.
kernel-patch-2.4.x-debian would be rather large as well.
kernel-patch-2.4.x-ipsec makes things better.
kernel-source-2.4.x would then be able to be kernel.org schtuff
But, this would alleviate SOME of the problems. This would be NO DOUBT
very helpful. The Binary Kernel (as in the archives could have any an
all patches you see fit Herbert)
Would it NO doubt make entirely MUCH more sense, to only have to D/L the
Source Code once. It would definitely reduce the bandwidth needed for
making successive revisions of the patched kernel much less storage
required as well.
Please... At least consider the things that are being said(typed)...
that you patently refuse to even consider.
--
greg, [EMAIL PROTECTED]
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry
Cher ami, votre tendre chapeau a heurte trois de mes phalanges avec une
grace incomparable.
signature.asc
Description: This is a digitally signed message part
Re: Debian should not modify the kernels!
On Tue, Oct 07, 2003 at 09:48:32AM -0400, Greg Folkert wrote: But, this would alleviate SOME of the problems. This would be NO DOUBT very helpful. The Binary Kernel (as in the archives could have any an all patches you see fit Herbert) Would it NO doubt make entirely MUCH more sense, to only have to D/L the Source Code once. Would it be POSSIBLE to LOSE the Zippy-style CAPITALIZATION, please? Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
On Monday, Oct 6, 2003, at 16:20 US/Eastern, martin f krafft wrote: It has existed in the freeswan patch for a while! Let's be serious, FreeS/WAN has serious issues! Being at war with the kernel routing machinery, for example.
Re: Debian should not modify the kernels!
On Monday, Oct 6, 2003, at 18:58 US/Eastern, Adam McKenna wrote: I don't see how the package being in unstable affects any part of this argument. Will the feature backport be less desirable when the kernel-source package is released in a stable revision of Debian? The whole point of not doing feature backports to stable is to keep stable stable. You won't see a security upgrade in stable that also happens to replace the VFS layer, for example. If I install woody on a system, I expect it to continue working essentially the same way --- minus security holes --- until I upgrade to sarge. Replacing the kernel IP stack in woody would thus be a no-no. The argument doesn't apply if I'm tracking unstable. If I track unstable I should expect that stuff will change relatively routinely, possibly causing breakage. That is why it's called unstable, after all. If the IPSec patched kernels make it into sarge, that's fine. Major changes are expected between woody and sarge as they are with ANY new stable release.
Re: Debian should not modify the kernels!
On Tue, 2003-10-07 at 09:51, Colin Watson wrote: On Tue, Oct 07, 2003 at 09:48:32AM -0400, Greg Folkert wrote: Would it NO doubt make entirely MUCH more sense, to only have to D/L the Source Code once. Would it be POSSIBLE to LOSE the Zippy-style CAPITALIZATION, please? Would it be *POSSIBLE* for you to *CHOP* off your arms? I have been posting like that for years. If you knew me personally, you'd understand, it goes with the way I speak or tell stories. I can provide you examples showing over 10 years of it being my norm. And you are about the... first one to be annoyed and voice it. Colin, this crap about the Kernel Source has gotten me wanting to express my views with more notice in them. It has become more of a pain to fix Herbert's proactive measures with feature enhancements rather then just getting things done. Sure I like IPSEC in the stack... but when I want to patch it in. 2.6.x is a different story. kill-file me if you don't like the cApItIzAtIoN. (at least it is not |-|4xX0rZ tYp3 and is readable.) -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry You have the vocabulary of an aspidistra in panic. signature.asc Description: This is a digitally signed message part
Re: Debian should not modify the kernels!
also sprach Anthony DeRobertis [EMAIL PROTECTED] [2003.10.07.1935 +0200]: It has existed in the freeswan patch for a while! Let's be serious, FreeS/WAN has serious issues! Being at war with the kernel routing machinery, for example. Alright, I give you that. But it works. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpuA82ITeDHP.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Eduard Bloch [EMAIL PROTECTED] [2003.09.22.1155 +0200]: Me too - if we have to have significantly modified kernels, they should be labelled as being such. They are - look at the last part of the kernel-image-KVERS image. So 2.4.22-686 indicates a 2.5 IPsec backport? Reality check please. grsec modifies the kernel so heavily that it will ALWAYS conflict with something when you modify the kernel a bit more that with trivial bugfixes. The same would happen if it conflicts with ANY of the 93 kernel-patches in the archive - there is no reason for rants on -devel. It does not conflict with preempt freeswan xfs debianlogo systrace uml usagi ltt lowlatency kdb lkcd badram vlan adaptec and these are just the ones I've tried. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgp6JmuojWHtT.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Osamu Aoki [EMAIL PROTECTED] [2003.09.22.0026 +0200]: Can your patch file to be more modular like X package? It is a big chunk. This would be a solution, but it would be an ugly solution. I still don't believe that the grsecurity patch should have to unpatch even parts of kernel-patch-debian to be applicable. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpobbzCxm77p.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Eduard Bloch [EMAIL PROTECTED] [2003.09.22.1207 +0200]:
Let's create a package called linux-2.4.22 or
linux-2.4.22-pure-vanilla-source-for-you-to-patch with a script which
does exactly this.
I oppose. Let's get rid of kernel-{source,image,etc.} and provide
linux-kernel-*. Then provide kernel-patch-debian and
kernel-patch-ipsec as separate packages!
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft [EMAIL PROTECTED]
: :' :proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
pgpaCt6tiv41A.pgp
Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.22.1331 +0200]: It is unacceptable for us to distribute kernels with known (security) bugs. It is unacceptable for us to backport features alongside security patches. From http://www.debian.org/security/faq: The most important guideline when making a new package that fixes a security problem is to make as few changes as possible. Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. Also, 5.8.5.3 of the Developer's Reference is a necessary read for this discussion. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpJnb9zSGcjL.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.27.1253 +0200]: There is no good reason for the grsec patch to require a vanilla kernel tree, merely one that is slightly less patched than the current Debian one. There is a good reason why grsec can require a kernel source that is 2.4.22 inside, if it says 2.4.22 on the outside. The right way to deal with this is to be able to trivially patch and unpatch the kernel source as required during building. If I could request for just the IPsec patch to be removed when grsec patches the kernel, that would be okay, but not acceptable really. Why go through the trouble of unpatching when Debian's really all about bottom-up? On a Debian system, I do not first go off to disable all the useless junk other distributions install. On a Debian system, I do not have to disable all the bells and whistles of some of the programs. I do not have to disable PHP in Apache, I don't have to disable open-relaying in the MTAs. However, I can choose to do all these once the default installation has left me with the basic installation. Why should the patching mechanism around the kernel be different? Now, I understand that security backports are necessary. But even hardware enhancements are out of place, along with feature backports! If I buy a network card known to work with 2.4.22 and up, I would not install 2.4.21 hoping that Herbert would have included the patch. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpKltJKg5vxE.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 09:45:13PM +0200, martin f krafft wrote: also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.22.1331 +0200]: It is unacceptable for us to distribute kernels with known (security) bugs. It is unacceptable for us to backport features alongside security patches. From http://www.debian.org/security/faq: The most important guideline when making a new package that fixes a security problem is to make as few changes as possible. Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. I beg your pardon? Why do you believe that the _stable distribution security FAQ_ is relevant to this argument? Also, 5.8.5.3 of the Developer's Reference is a necessary read for this discussion. Ditto. When an update is made to the stable release, -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Debian should not modify the kernels!
also sprach Mark Brown [EMAIL PROTECTED] [2003.09.22.1109 +0200]: Well, what you seem to want is to have the kernel source avaliable in a format that makes packaging kernel patches easy. That seems like a different issue to me. No, this is the issue. I want the kernel sources to be what they promise, and not what Herbert wants them to be. I can opt-in on have the bells and whistles Herbert thinks should belong in every kernel-image, but if I don't make that choice, I want to have the kernel-source with just the security fixes. After all, Debian is known for two things: purity and security. I don't see the first one applying to kernel-source, and given that IPsec is in beta state, I don't see the second either. Moreover: 2.4 users have the choice to run IPsec: FreeS/WAN works just fine, and it happily coexists with grsecurity. It's also just another IPsec stack. Weird, huh? Maybe the 2.5 IPsec stack does patch more than add an IPsec stack? Herbert? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpNu5KXLc1J3.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.09.24.2214 +0200]: make-kpkg and kernel-patches/modules work just fine with vanilla sources. Except with --initrd. I never need initrd if I make my own kernels. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpsgq75EDqFa.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Greg Folkert [EMAIL PROTECTED] [2003.09.28.0209 +0200]: Would that then allow you to NOT include it in the kernel-source package, but then make it a standard patch to be installed by default then? And have a Variable NO_IPSEC_PATCH or something similar so that kpkg doesn't apply it... but does apply other patches. not another variable! -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpXGbWryqLWk.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.28.0510 +0200]: For example, the grsecurity patch has had a history of conflicts with various patches in the Debian kernel source. Most of those patches that caused conflicts were in fact essential security fixes. You can review this for yourself by visiting to the BTS entry for the grsecurity package. If it's a small security fix, then I am willing to work that into grsecurity. But I won't port grsecurity to a new IP stack nor the other way around. Also, please provide a reference to the history of conflicts of the grsecurity patch. All the conflicts I have fixed were mainly related to line offset shifts. I don't consider those conflicts. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpxfFfn4mfic.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach [EMAIL PROTECTED] [EMAIL PROTECTED] [2003.09.28.0605 +0200]: That has more to do with the fact that grsecurity is an intrusive pile of garbage, I'd appreciate if you kept your opinions to yourself, or state them in a less aggressive fashion. Look, it's that simple - authors of patch had chosen to be antisocial and kept it a monolit; that makes it a second-class citizen as far as merges are concerned. Less intrusive patches get precedence. End of story. Funny you mention that. Any implications on the class this puts Herbert in? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpZRk6cYHKvT.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Matt Zimmerman [EMAIL PROTECTED] [2003.09.29.0232 +0200]: Hear, hear. IPsec in particular is long overdue in the Linux kernel and I am glad to see it. It has existed in the freeswan patch for a while! -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpCujAf1qu7Y.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Daniel Jacobowitz [EMAIL PROTECTED] [2003.10.06.2220 +0200]: I beg your pardon? Why do you believe that the _stable distribution security FAQ_ is relevant to this argument? Because it is the only thing I could find that reflects Debian's take on security fixes: feature backports are to be avoided. Branden correctly states that feature imports are frequently used in other packages, but you can't name a single package on whose byte-by-byte code other packages depend. kernel-source is the only one, I believe, and so it takes a special role. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpmB25nM8XNb.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach martin f krafft [EMAIL PROTECTED] [2003.09.30.1016 +0200]: How do y'all suggest we continue on this, because apparently there are two camps with different opinions, Herbert doesn't think he needs to do anything, and this issue will just die without a change happening. I think we have to properly address and close the whole thing! Apparently noone agrees with me. I can't help but state that I am rather pissed off! I am especially annoyed with Herbert, who refused to make even the slightest budge in a direction showing his willingness to cooperate. I am sick and tired of these it's your problem and it's my choice excuses. Debian is a cooperative effort, it's not a conglomeration of hundreds of maintainers that do their own thing with their own packages. If I hadn't learnt to sleep over some issues in the past, I'd resign from the project right here. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpLYyfxtEKuK.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 10:41:47PM +0200, martin f krafft wrote: also sprach martin f krafft [2003.09.30.1016 +0200]: How do y'all suggest we continue on this, because apparently there are two camps with different opinions, Herbert doesn't think he needs to do anything, and this issue will just die without a change happening. I think we have to properly address and close the whole thing! Apparently noone agrees with me. I agree that the Debian kernel sources shouldn't contain any feature backports that aren't specifically to address security issues. I'd prefer a kernel source package with as few changes as possible. However, I also agree that it's Herbert's perrogative as pacakge maintainer to package what he wants (short of a policy violation or general resolution). I can't help but state that I am rather pissed off! I am especially annoyed with Herbert, who refused to make even the slightest budge in a direction showing his willingness to cooperate. I am sick and tired of these it's your problem and it's my choice excuses. Debian is a cooperative effort, it's not a conglomeration of hundreds of maintainers that do their own thing with their own packages. Sadly, you must be seeing a different Debian that I've seen. Sure the developers frequently work together toward an end goal, but I've seen meantion of a few cases of developers maintaining their packages exactly the way they want regardless of what other have to say. You've always got the option of packaging a new kernel source package without the excess. -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 10:08:57PM +0200, martin f krafft wrote: also sprach Mark Brown [EMAIL PROTECTED] [2003.09.22.1109 +0200]: Well, what you seem to want is to have the kernel source avaliable in a format that makes packaging kernel patches easy. That seems like a different issue to me. No, this is the issue. I want the kernel sources to be what they promise, and not what Herbert wants them to be. I can opt-in on have the bells and whistles Herbert thinks should belong in every kernel-image, but if I don't make that choice, I want to have the kernel-source with just the security fixes. After all, Debian is known for two things: purity and security. I don't see the first one applying to kernel-source, and given that IPsec is in beta state, I don't see the second either. I agree with Martin. If patches in the base package make additional kernel patch packages impossible, they should not be applied. Users should have the choice which patches they want to apply. So the proper way IMHO is to provide a vanilla kernel-source package and an IPSec backport package. Moreover: 2.4 users have the choice to run IPsec: FreeS/WAN works just fine, and it happily coexists with grsecurity. It's also just another IPsec stack. Weird, huh? Maybe the 2.5 IPsec stack does patch more than add an IPsec stack? Herbert? BTW, I do not use the kernel-source package, I always build my own kernel using make-kpkg - with cryptoloop patch. But that's not the point. If I find that that patch conflicts with the Debian kernel source, I would get very irritated. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 10:32:20PM +0200, martin f krafft wrote: also sprach Daniel Jacobowitz [EMAIL PROTECTED] [2003.10.06.2220 +0200]: I beg your pardon? Why do you believe that the _stable distribution security FAQ_ is relevant to this argument? Because it is the only thing I could find that reflects Debian's take on security fixes: feature backports are to be avoided. That's because it's the position of the *Security Team*, and is certainly not binding on other developers who are making changes to packages in *unstable*. -- Steve Langasek postmodern programmer pgpMtMPI9xh7K.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Tue, Oct 07, 2003 at 12:30:45AM +0200, Oliver Kurth wrote: On Mon, Oct 06, 2003 at 10:08:57PM +0200, martin f krafft wrote: also sprach Mark Brown [EMAIL PROTECTED] [2003.09.22.1109 +0200]: Well, what you seem to want is to have the kernel source avaliable in a format that makes packaging kernel patches easy. That seems like a different issue to me. No, this is the issue. I want the kernel sources to be what they promise, and not what Herbert wants them to be. I can opt-in on have the bells and whistles Herbert thinks should belong in every kernel-image, but if I don't make that choice, I want to have the kernel-source with just the security fixes. After all, Debian is known for two things: purity and security. I don't see the first one applying to kernel-source, and given that IPsec is in beta state, I don't see the second either. I agree with Martin. If patches in the base package make additional kernel patch packages impossible, they should not be applied. Users should have the choice which patches they want to apply. As stated above, this is not a reasonable restriction. An arbitrary kernel patch package might conflict with *any* changes made to the kernel-source package, including simple security fixes. The kernel-source maintainer must have some flexibility to maintain his packages in the manner he believes best meets their primary purpose, which AIUI is to provide a suitable base from which to build kernel-image packages to be distributed in Debian. The burden is on the kernel patch maintainer to provide something which works with the packages it depends on. If this is achieved by *persuading* the kernel source maintainer to revert a given patch, so much the better; but there's one kernel source maintainer and n kernel patch maintainers -- it's clear which end rightly bears the responsibility of making those n packages work. -- Steve Langasek postmodern programmer pgphJ3HJcFE2F.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote: Because it is the only thing I could find that reflects Debian's take on security fixes: feature backports are to be avoided. That's because it's the position of the *Security Team*, and is certainly not binding on other developers who are making changes to packages in *unstable*. I don't see how the package being in unstable affects any part of this argument. Will the feature backport be less desirable when the kernel-source package is released in a stable revision of Debian? --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 06:04:45PM -0500, Steve Langasek wrote: On Tue, Oct 07, 2003 at 12:30:45AM +0200, Oliver Kurth wrote: On Mon, Oct 06, 2003 at 10:08:57PM +0200, martin f krafft wrote: also sprach Mark Brown [EMAIL PROTECTED] [2003.09.22.1109 +0200]: Well, what you seem to want is to have the kernel source avaliable in a format that makes packaging kernel patches easy. That seems like a different issue to me. No, this is the issue. I want the kernel sources to be what they promise, and not what Herbert wants them to be. I can opt-in on have the bells and whistles Herbert thinks should belong in every kernel-image, but if I don't make that choice, I want to have the kernel-source with just the security fixes. After all, Debian is known for two things: purity and security. I don't see the first one applying to kernel-source, and given that IPsec is in beta state, I don't see the second either. I agree with Martin. If patches in the base package make additional kernel patch packages impossible, they should not be applied. Users should have the choice which patches they want to apply. As stated above, this is not a reasonable restriction. An arbitrary kernel patch package might conflict with *any* changes made to the kernel-source package, including simple security fixes. The Security fixes are another matter. If it conflicts with a patch, so be it, but in that case the maintainer of that patch is responsible to change the patch accordingly - which should not be difficult. kernel-source maintainer must have some flexibility to maintain his packages in the manner he believes best meets their primary purpose, which AIUI is to provide a suitable base from which to build kernel-image packages to be distributed in Debian. How can a vanilla kernel prevent the packager to build (any) kernel images? Or how does a kernel, built with any patches, hinder from building kernel-images? The burden is on the kernel patch maintainer to provide something which works with the packages it depends on. If this is achieved by *persuading* the kernel source maintainer to revert a given patch, so much the better; but there's one kernel source maintainer and n kernel patch maintainers -- it's clear which end rightly bears the responsibility of making those n packages work. So it's the kernel source maintainer, because that's only one person? Sorry, I have the feeling that I missed something. Greetings, Oliver, going to sleep now. -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Debian should not modify the kernels!
On 2003-10-06, Adam McKenna [EMAIL PROTECTED] wrote: On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote: Because it is the only thing I could find that reflects Debian's take on security fixes: feature backports are to be avoided. That's because it's the position of the *Security Team*, and is certainly not binding on other developers who are making changes to packages in *unstable*. I don't see how the package being in unstable affects any part of this argument. Will the feature backport be less desirable when the kernel-source package is released in a stable revision of Debian? Yes. Once the kernel-source is in a stable revision, feature backports of *new* features will be undesirable. The point of the policy is to prevent behaviour from changing without warning or unnecessarily. Peace, Dylan
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 03:58:07PM -0700, Adam McKenna wrote: On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote: Because it is the only thing I could find that reflects Debian's take on security fixes: feature backports are to be avoided. That's because it's the position of the *Security Team*, and is certainly not binding on other developers who are making changes to packages in *unstable*. I don't see how the package being in unstable affects any part of this argument. Will the feature backport be less desirable when the kernel-source package is released in a stable revision of Debian? Being desirable or not doesn't matter, because there's a policy about what kinds of changes will be accepted to stable releases of packages -- a policy enforced by the stable release manager and the security team. This is a policy governing *the scope of changes made to released packages*, and does not limit what developers are allowed to do to packages prior to release. The difference is clear when you consider that this policy is being used to argue against deviating from upstream releases, when in fact the security backport policy *invariably* results in deviation from upstream releases in stable security updates. So you can argue for whatever set of rules you'd like, but that does not make it Debian's take on security fixes (to packages in unstable). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote: On Mon, Oct 06, 2003 at 10:32:20PM +0200, martin f krafft wrote: also sprach Daniel Jacobowitz [EMAIL PROTECTED] [2003.10.06.2220 +0200]: I beg your pardon? Why do you believe that the _stable distribution security FAQ_ is relevant to this argument? Because it is the only thing I could find that reflects Debian's take on security fixes: feature backports are to be avoided. That's because it's the position of the *Security Team*, and is certainly not binding on other developers who are making changes to packages in *unstable*. It still encapsulates an excellent way of avoiding messes like this, and maintains the principle of least suprise for users. Finding out that your Debian kernel source is mostly vanilla, with security fixes, is one thing. Finding that it's vanilla, plus security fixes, plus whichever kitchen sinks (sorry, but IPSec can't be anything BUT a kitchen sink patch) the maintainer likes, but not ones s/he doesn't like, is quite another. However, Herbert clearly doesn't find this a convincing line of argument on it's own merits, so it's probably time to just kill this off. If someone cares enough to do it this way, package it and upload it (and if ftpmaster denies it, then we have something to talk about). If nobody cares enough, then - well, nobody cares enough. Makes it pretty simple. I'd still *rather* have it done more sanely, and intend to do so for the NetBSD kernel sources, but short of the Technical Committee (who might quite possibly decide it's fine), there doesn't seem to be much to be done at this point except correct the situation by way of providing a better answer. (I am, however, reminded that it's probably a good idea to go codify some things in the proposed mini-policy for NetBSD kernels...) -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp0GlaaATxTZ.pgp Description: PGP signature
Re: Debian should not modify the kernels!
* Herbert Xu | Very few people really need cramfs if they're building custom kernels. | This is because initrd only makes sense when you're building for a | large number of machines. If you're building a custom kernel, just | compile in all the drivers you need for mounting root and that's that. Except if you want to use EVMS or similar on /, in which case you need the evms userspace tools on the initrd. (Using 2.6, that is, in 2.4 the discovery is done in kernel-space.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Debian should not modify the kernels!
Tollef Fog Heen [EMAIL PROTECTED] wrote:
* Herbert Xu
| Very few people really need cramfs if they're building custom kernels.
| This is because initrd only makes sense when you're building for a
| large number of machines. If you're building a custom kernel, just
| compile in all the drivers you need for mounting root and that's that.
Except if you want to use EVMS or similar on /, in which case you need
the evms userspace tools on the initrd. (Using 2.6, that is, in 2.4
the discovery is done in kernel-space.)
That's right.
But even in that case you don't need cramfs as romfs should work.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debian should not modify the kernels!
Hi, thanks the good maintenance by Herbert, On Sun, Sep 28, 2003 at 08:12:43AM +1000, Herbert Xu wrote: Andreas Metzler [EMAIL PROTECTED] wrote: martin f krafft [EMAIL PROTECTED] wrote: What I'd really like to hear is a reaction from Herbert to: Osamu Aoki [EMAIL PROTECTED] in [EMAIL PROTECTED] | Can your patch file to be more modular like X package? It is a big | chunk. Which could make both sides happy. Instead of one big patch containing bugfixes, security fixes and feature additions to make them separately available in the kernel-source-package. Again this is something that I have already stated my position on. This is simply unmaintainable due to the complex relationships between patches. Interesting :-) My use of word modular may have mislead you as I see above. Just to avoid confusion: 1) I like default kernel get good maintenance including IPsec if the expert Herbert Xu decides to do so. (No argument here from me.) 2) I was not suggesting very fine grained modular patch for each issues. I was expecting something like 3-4 stage patches. * 1st big patch: cramfs etc. which are essential to be Debian kernel * 2nd big patch: basic bug fixes. (No feature change, something you may have got from upstream pre release patch.) * 3rd big patch: basic feature fix. (IPsec and all others which is generally good and nice for most users.) * 4th big patch: Whatever you did at last minutes :-) The order of above is not essential for me. It should apply clean though. In any case, the kernel-source package's README file should contain all the information you need to extract any particular patch that you're interested in. If you make your patch somewhat more split into staged manner (yes, I am not asking modular), then it is easier for specialty patch maintenance become easy. After all those specialty patch user may no need features needed by most user but he certainly expects having cramfs and other standard features of Debian. If you claim making simple 3-4 stage patch maintenance unmaintainable due to the complex relationships between patches, it is certainly unmaintainable for other patch package maintainer or any one try to apply patch to keep up with you. I know you maintain position that other patch maintainer can do 1st and 2nd stage patch himself using vanilla source after unpatch. But, to me, it is waisted resources. I did not understand why you want to document how you build package only in the text of documentation but not in source package itself. Cheers, Osamu PS: I once wanted to apply ACPI patch and hit similar issues as Martin. It was too much for me and I gave up :-( Now Debian version of kernel is 2.4.21 and I am happy.
Re: Debian should not modify the kernels!
Osamu Aoki [EMAIL PROTECTED] wrote:
2) I was not suggesting very fine grained modular patch for each issues.
I was expecting something like 3-4 stage patches.
* 1st big patch: cramfs etc. which are essential to be Debian kernel
* 2nd big patch: basic bug fixes. (No feature change, something you
may have got from upstream pre release patch.)
* 3rd big patch: basic feature fix. (IPsec and all others which is
generally good and nice for most users.)
* 4th big patch: Whatever you did at last minutes :-)
The order of above is not essential for me. It should apply clean
though.
No this is still a lot of work for very little gain.
The problem is that everytime a change is made in the first patch, all
the other three will have to be fixed and rengenerated.
If you make your patch somewhat more split into staged manner (yes, I
am not asking modular), then it is easier for specialty patch
maintenance become easy. After all those specialty patch user may no
need features needed by most user but he certainly expects having cramfs
and other standard features of Debian.
Very few people really need cramfs if they're building custom kernels.
This is because initrd only makes sense when you're building for a
large number of machines. If you're building a custom kernel, just
compile in all the drivers you need for mounting root and that's that.
On the other hand, the security fixes are usually easy to extract and
well documented.
If you claim making simple 3-4 stage patch maintenance unmaintainable
due to the complex relationships between patches, it is certainly
unmaintainable for other patch package maintainer or any one try to
apply patch to keep up with you.
Keeping up with the Debian tree is much the same as keeping up with
any other kernel tree. The answer is to use a proper revision control
system.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debian should not modify the kernels!
also sprach Adam Borowski [EMAIL PROTECTED] [2003.09.28.0744 +0200]: Well... as 2.6 is coming out really soon, ipsec is in a lot better position than grsec. Also, you will _have_ to port grsec to 2.6 (or abandon it), and 2.6 will have ipsec in the upstream sources. The only difference lies in needing to do the porting work a bit sooner. Bollocks. I am the Debian maintainer, I won't do any porting. grsecurity will support the 2.6 kernel series when it is released. Then I will port the new patches to Debian. Then, the problem will be fixed. However, I still don't think that this closes the issue. I think feature backports to the kernel-source packages should not happen! How do y'all suggest we continue on this, because apparently there are two camps with different opinions, Herbert doesn't think he needs to do anything, and this issue will just die without a change happening. I think we have to properly address and close the whole thing! -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpNbHcjozcvY.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Sun, 28 Sep 2003 20:32:36 -0400, Matt Zimmerman [EMAIL PROTECTED] wrote: Hear, hear. IPsec in particular is long overdue in the Linux kernel and I am glad to see it. Please note that the 2.6 ipsec is unuseable. You can't filter traffic that goes into or comes from a tunnel. That's a killer. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Debian should not modify the kernels!
Marc Haber [EMAIL PROTECTED] wrote:
Please note that the 2.6 ipsec is unuseable. You can't filter traffic
that goes into or comes from a tunnel. That's a killer.
That's not true. Filtering for tunnels works just fine.
Transport mode filtering is indeed not supported. But you can achieve
the same effect through IPSEC policies.
The only show stopper with tunnels is the lack of SNAT support. Even
that isn't very difficult to resolve.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debian should not modify the kernels!
also sprach Herbert Xu [EMAIL PROTECTED] [2003.09.28.0012 +0200]: As I have said before, kernel-source's primary purpose is for building default Debian kernel images. Thus it should contain all the patches necessary so that the images are uniform across architectures. IPsec is not necessary. If someone wants to make a kernel-patch package out of it, go right ahead. This is not responsible behaviour from a Debian maintainer, Herbert, and you know it. [...] This is simply unmaintainable due to the complex relationships between patches. So you offload the work to others... In any case, the kernel-source package's README file should contain all the information you need to extract any particular patch that you're interested in. We are not interested in a patch, we are interested in feature backports being removed from kernel-source. Nowhere else does Debian have feature backports, the entire security update system is structured around the belief that this is *a bad thing*, and you are just being a incredibly difficult and non-cooperative about it. Are we going to need a formal vote to open your eyes? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpfvD0U7YJdH.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, Sep 29, 2003 at 11:06:00PM +0200, martin f krafft wrote: Nowhere else does Debian have feature backports, That's not true. Feature backports are occasionally incidental in, e.g, XFree86 package updates when snatching a newer version of a driver for its bugfixes, and the code has changed too much to make backporting the bugfixes by themselves tedious. the entire security update system is structured around the belief that this is *a bad thing*, and you are just being a incredibly difficult and non-cooperative about it. There's a difference between security updates, proposed updates for released versions of the Debian OS, and updates to unstable. -- G. Branden Robinson| The National Security Agency is Debian GNU/Linux | working on the Fourth Amendment [EMAIL PROTECTED] | thing. http://people.debian.org/~branden/ | -- Phil Lago, Deputy XD, CIA signature.asc Description: Digital signature
Re: Debian should not modify the kernels!
On Sun, Sep 28, 2003 at 01:10:27PM +1000, Herbert Xu wrote: I do not believe that this patch has caused excessive grief for the benefits that it brings. In fact, conflicts between the Debian kernel source and random kernel patches floating around are a fact of life. For example, the grsecurity patch has had a history of conflicts with various patches in the Debian kernel source. Most of those patches that caused conflicts were in fact essential security fixes. You can review this for yourself by visiting to the BTS entry for the grsecurity package. That has more to do with the fact that grsecurity is an intrusive pile of garbage, splashed pretty much all over the tree (which, incidentally, is a large part of reasons why it is unfit for upstream kernel). For crying out loud, it's a half-megabyte monolitic patch. Even devfs was slightly smaller when it had finally dripped into the tree. If somebody wants to play with it - they'll have to either a) split the damn thing into series of localized chunks and enjoy relatively easy resolution of conflicts with other patches or b) wear I'm a sadomasochist and proud of it T-shirt and leave everybody else alone. Look, it's that simple - authors of patch had chosen to be antisocial and kept it a monolit; that makes it a second-class citizen as far as merges are concerned. Less intrusive patches get precedence. End of story.
Re: Debian should not modify the kernels!
On Sat, 27 Sep 2003, George Danchev wrote: 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... Well... as 2.6 is coming out really soon, ipsec is in a lot better position than grsec. Also, you will _have_ to port grsec to 2.6 (or abandon it), and 2.6 will have ipsec in the upstream sources. The only difference lies in needing to do the porting work a bit sooner. 1KB /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped)
Re: Debian should not modify the kernels!
On Sat, 2003-09-27 at 23:10, Herbert Xu wrote: Greg Folkert [EMAIL PROTECTED] wrote: So which of the 11 platforms _REQUIRE_ the IPSEC backport? If any, what is the rational that they *REQUIRE* that piece. As for the criteria for inclusion, I have already outlined some simple rules earlier in this thread. I would recommend you to read it if you are interested. Yes but those criterion fail to mention why it is required in the Debian Kernel Source. I understand it should be in the default Binary images... but as for inclusion into the default source, still begs the question _why_ is it required, as your simple statement doesn't cover that. As far as benefits it provides *I* can see it being beneficial, but still fail to see why since the entire thrust of Debian is all about choice and not including everything by default and making some things optional. I really have no problem with the distributed Binary Kernels including this patch, but do think additional feature should be included as a patch *to* the source, not *for removal*. And, just for grins and giggles here, if lets say that 90% of the patches available to the patch system were, in fact, actively maintained and have been/are candidates for inclusion in the Kernel by the Kernel Core Team (err maybe just Linus) would you then be including all of them as included patches and backports to the Debian Kernel source 2.4? One more thing, why have you not included the IPSEC piece in the 2.2 Source then? If someone wants to make a kernel-patch package out of it, go right ahead. Would that then allow you to NOT include it in the kernel-source package, but then make it a standard patch to be installed by default then? And have a Variable NO_IPSEC_PATCH or something similar so that kpkg doesn't apply it... but does apply other patches. No, the purpose of such a kernel-patch package would be to allow a user to easily obtain the IPSEC patch should they wish to either apply it to a vanilla kernel, or unapply it from the Debian kernel. Its existence is orthogonal to whether this patch is included in the Debian kernel source. Again, why should it be orthogonal, seems opposite about why we even HAVE the Kernel Patching in kpkg at all then. Let us go back to using patch then. But exactly why should this particular patch (IPSEC backport) cause so much grief for the patch system, if it were to be so standard? I do not believe that this patch has caused excessive grief for the benefits that it brings. In fact, conflicts between the Debian kernel source and random kernel patches floating around are a fact of life. For example, the grsecurity patch has had a history of conflicts with various patches in the Debian kernel source. Most of those patches that caused conflicts were in fact essential security fixes. You can review this for yourself by visiting to the BTS entry for the grsecurity package. To be honest you are very right in this, in general though, why should you add insult to injury on this by making the the situation worse? Granted grsecurity and a few other patches, really screw with the source quite a bit, but I still fail to see why these need to be included by default Might just be we agree to disagree? And if I felt compelled to... could I maintain a kernel-source that only has bug and security fixes in it with no additional features added? Would you sponsor it? (Rhetorically asked) -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry Your eyes are much like milky pools of pantyhose. signature.asc Description: This is a digitally signed message part
Re: Debian should not modify the kernels!
On Sep 28, Greg Folkert [EMAIL PROTECTED] wrote: Yes but those criterion fail to mention why it is required in the Debian Kernel Source. I understand it should be in the default Binary images... but as for inclusion into the default source, still begs the question _why_ is it required, as your simple statement doesn't cover that. If you want an unmodified kernel then download it from a kernel.org mirror. Debian is supposed to ship an *useful* kernel. -- ciao, | Marco | [2150 os5doX61yZxwg] signature.asc Description: Digital signature
Re: Debian should not modify the kernels!
On Sun, Sep 28, 2003 at 06:08:45PM +0200, Marco d'Itri wrote: On Sep 28, Greg Folkert [EMAIL PROTECTED] wrote: Yes but those criterion fail to mention why it is required in the Debian Kernel Source. I understand it should be in the default Binary images... but as for inclusion into the default source, still begs the question _why_ is it required, as your simple statement doesn't cover that. If you want an unmodified kernel then download it from a kernel.org mirror. Debian is supposed to ship an *useful* kernel. Hear, hear. IPsec in particular is long overdue in the Linux kernel and I am glad to see it. -- - mdz
Re: Debian should not modify the kernels!
On Sun, 2003-09-28 at 12:08, Marco d'Itri wrote: On Sep 28, Greg Folkert [EMAIL PROTECTED] wrote: Yes but those criterion fail to mention why it is required in the Debian Kernel Source. I understand it should be in the default Binary images..
Re: Debian should not modify the kernels!
On Wed, 24 Sep 2003 16:14:03 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Mon, Sep 22, 2003 at 08:03:50PM +0200, martin f krafft wrote: also sprach Martin Pitt [EMAIL PROTECTED] [2003.09.22.1343 +0200]: However, they might be useful to people using make-kpkg and patch packages to get the right dependencies and ease the download. Thus I would not vote to throw them out completely. make-kpkg and kernel-patches/modules work just fine with vanilla sources. Except with --initrd. Even if you configure the postinst to use genromfs? manoj -- God is love, but get it in writing. Gypsy Rose Lee Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Debian should not modify the kernels!
On Wed, Sep 24, 2003 at 04:47:13PM -0500, Chad Walstrom wrote: Doesn't this have to do with the cramfs patch? Man, this is quite the delay. I guess that's what I get for misconfiguring my email server with the wrong origin setting. ;-) -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpxcqCPKG2aH.pgp Description: PGP signature
Re: Debian should not modify the kernels!
martin f krafft [EMAIL PROTECTED] wrote: This thread has been going on for a while, and I think the general voice has been that security backports and other vital patches are totally alright for kernel-source. However, I think the general agreement is that feature backports are not okay. That's what kernel-patches are for. I would like to hear an official statement by Herbert on this. We should not let this thread extend to infinity, but come to conclusions and implement them in time for the Sarge release. What I'd really like to hear is a reaction from Herbert to: Osamu Aoki [EMAIL PROTECTED] in [EMAIL PROTECTED] | Can your patch file to be more modular like X package? It is a big | chunk. Which could make both sides happy. Instead of one big patch containing bugfixes, security fixes and feature additions to make them separately available in the kernel-source-package. cu andreas
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 [EMAIL PROTECTED] [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
Re: Debian should not modify the kernels!
Le Mardi 23 Septembre 2003 18:21, Steve Greenland a écrit : On 22-Sep-03, 14:14 (CDT), Florian Weimer [EMAIL PROTECTED] wrote: It's a well accepted fact among kernel developers that vanilla kernel.org kernels should not be used by end users. Debian has to patch the kernel, too. There isn't much choice. Agreed, but there's a significant difference between including bug fixes and de-facto required architecture-specific updates and including a completely new subsystem backported from 2.5 yet calling it 2.4. For $DIETY's sake, we keep ALSA as a separate patch/module, why is putting in IPSEC justified? i agree with that what i like most in debian is the kernel-patch-xxx system, i regulary build freeswan, mppe enabled kernel and the 2.422 i am testing now give me loots of problems. i surely will prefer a separate kernel-patch-ipsec package an if not possible at least two patch files in the kernel 2.4.22 package, one with all the classical bits like bigmem etc.. and one other with the ipsec patch so we can desactive this one if needed. thanks -- OpenSides sprl Free Software Specialist Benoit Mortier - Linux Engineer pgp91zlXP9x15.pgp Description: signature
Re: Debian should not modify the kernels!
George Danchev wrote: 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. That's the crux of the matter. The current situation is broken because it makes it difficult to add extra patches to the kernel-source package without removing the entirity of the Debian patch, not because the kernel-source package isn't vanilla. There is no good reason for the grsec patch to require a vanilla kernel tree, merely one that is slightly less patched than the current Debian one. The right way to deal with this is to be able to trivially patch and unpatch the kernel source as required during building. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
Andreas Metzler [EMAIL PROTECTED] wrote:
martin f krafft [EMAIL PROTECTED] wrote:
This thread has been going on for a while, and I think the general
voice has been that security backports and other vital patches are
totally alright for kernel-source. However, I think the general
agreement is that feature backports are not okay. That's what
kernel-patches are for.
That has not been my impression at all.
As I have said before, kernel-source's primary purpose is for building
default Debian kernel images. Thus it should contain all the patches
necessary so that the images are uniform across architectures.
Having said that, I do understand that users will use it for building
custom images. But the presence of kernel-patch-debian fixes that
situation. You can easily obtain a vanilla kernel that you can apply
patches too.
Now for those who want to get rid of just the ipsec patch, that can
be done as well. Just download it from the URL specified in the README
file and unapply it.
If someone wants to make a kernel-patch package out of it, go right
ahead.
What I'd really like to hear is a reaction from Herbert to:
Osamu Aoki [EMAIL PROTECTED] in [EMAIL PROTECTED]
| Can your patch file to be more modular like X package? It is a big
| chunk.
Which could make both sides happy. Instead of one big patch containing
bugfixes, security fixes and feature additions to make them separately
available in the kernel-source-package.
Again this is something that I have already stated my position on.
This is simply unmaintainable due to the complex relationships between
patches.
In any case, the kernel-source package's README file should contain all
the information you need to extract any particular patch that you're
interested in.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debian should not modify the kernels!
On Sat, 2003-09-27 at 18:12, Herbert Xu wrote: Andreas Metzler [EMAIL PROTECTED] wrote: martin f krafft [EMAIL PROTECTED] wrote: This thread has been going on for a while, and I think the general voice has been that security backports and other vital patches are totally alright for kernel-source. However, I think the general agreement is that feature backports are not okay. That's what kernel-patches are for. That has not been my impression at all. As I have said before, kernel-source's primary purpose is for building default Debian kernel images. Thus it should contain all the patches necessary so that the images are uniform across architectures. So which of the 11 platforms _REQUIRE_ the IPSEC backport? If any, what is the rational that they *REQUIRE* that piece. Having said that, I do understand that users will use it for building custom images. But the presence of kernel-patch-debian fixes that situation. You can easily obtain a vanilla kernel that you can apply patches too. Now for those who want to get rid of just the ipsec patch, that can be done as well. Just download it from the URL specified in the README file and unapply it. If someone wants to make a kernel-patch package out of it, go right ahead. Would that then allow you to NOT include it in the kernel-source package, but then make it a standard patch to be installed by default then? And have a Variable NO_IPSEC_PATCH or something similar so that kpkg doesn't apply it... but does apply other patches. What I'd really like to hear is a reaction from Herbert to: Osamu Aoki [EMAIL PROTECTED] in [EMAIL PROTECTED] | Can your patch file to be more modular like X package? It is a big | chunk. Which could make both sides happy. Instead of one big patch containing bugfixes, security fixes and feature additions to make them separately available in the kernel-source-package. Again this is something that I have already stated my position on. This is simply unmaintainable due to the complex relationships between patches. In any case, the kernel-source package's README file should contain all the information you need to extract any particular patch that you're interested in. But exactly why should this particular patch (IPSEC backport) cause so much grief for the patch system, if it were to be so standard? -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry Your eyes glow like naked livers burning in the sun. signature.asc Description: This is a digitally signed message part
Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
On Fri, Sep 26, 2003 at 08:08:39AM +1000, Herbert Xu wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: I ran it through diffstat, and removed the files which are created entirely by the patch, so these are the changes to common code: I've had a look and it appears to be acceptable. Please file a bug report against kernel and I'll probably include it when 2.4.23 is released. Done. On a related note, there is some talk about device-mapper being included in a later 2.4.x kernel, but nothing concrete. -- - mdz
Re: Debian should not modify the kernels!
Greg Folkert [EMAIL PROTECTED] wrote:
So which of the 11 platforms _REQUIRE_ the IPSEC backport? If any, what
is the rational that they *REQUIRE* that piece.
As the current maintainer of kernel-source, I decide which patches
are included per default. The individual architecture maintainers
can choose to override my decisions through architecture patches.
As for the criteria for inclusion, I have already outlined some simple
rules earlier in this thread. I would recommend you to read it if you
are interested.
If someone wants to make a kernel-patch package out of it, go right
ahead.
Would that then allow you to NOT include it in the kernel-source
package, but then make it a standard patch to be installed by default
then? And have a Variable NO_IPSEC_PATCH or something similar so that
kpkg doesn't apply it... but does apply other patches.
No, the purpose of such a kernel-patch package would be to allow a user
to easily obtain the IPSEC patch should they wish to either apply it
to a vanilla kernel, or unapply it from the Debian kernel.
Its existence is orthogonal to whether this patch is included in the
Debian kernel source.
But exactly why should this particular patch (IPSEC backport) cause so
much grief for the patch system, if it were to be so standard?
I do not believe that this patch has caused excessive grief for the
benefits that it brings. In fact, conflicts between the Debian kernel
source and random kernel patches floating around are a fact of life.
For example, the grsecurity patch has had a history of conflicts with
various patches in the Debian kernel source. Most of those patches that
caused conflicts were in fact essential security fixes. You can review
this for yourself by visiting to the BTS entry for the grsecurity
package.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debian should not modify the kernels!
martin f krafft wrote: MFK make-kpkg and kernel-patches/modules work just fine with vanilla MFK sources. Matt Zimmerman wrote: MDZ Except with --initrd. Doesn't this have to do with the cramfs patch? Wasn't this patch rejected by Linus for some reason? IIRC, the cramfs patch is something very specific to Debian kernels and is a workaround for a cramfs bug. I did a google search on this because I wasn't familiar w/the current/past discussion on the topic. It looks like our reference documentation actually touches on this topic[1]. In any case, --initrd can be configured to use a different filesystem for the initrd in /etc/mkinitrd/mkinitrd.rc file. Could someone explain why we still use the cramfs route if it's not being adopted by the kernel gods in general? Is there a more accepted filesystem that gives us the benefits of cramfs? I saw one person suggest ISO. ext2 works fine. Perhaps cramfs' size profile was the smallest in the kernel, which made it a good solution for Debian? 1. http://www.debian.org/doc/manuals/reference/ch_kernel.en -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgphbDDQrDoKP.pgp Description: PGP signature
Re: Debian should not modify the kernels!
martin f krafft wrote: also sprach Matthew Garrett [EMAIL PROTECTED] [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. it's a chunk of code that has almost nothing to do with the core kernel code 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? -- Matthew Garrett | [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
Chris Cheney [EMAIL PROTECTED] wrote:
Is there a particular reason we are distributing old kernels at all? I
see the following in the archive:
They're needed by non-i386 architectures. Once a kernel-source is no
longer used by any architecture, it can be removed from Debian.
BTW - linux-2.6.0-test5 was released Sept 8.
Yes I know. I plan to stick to a monthly release schedule unless there
is something drastically wrong.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debian should not modify the kernels!
also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.25.0044 +0200]: 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 am not opposing having a patch provide that stack. it's a chunk of code that has almost nothing to do with the core kernel code In that it can be inserted without modifying behaviour of things that other parts of the kernel or userland depend upon. The IPsec part, yes. But a whole different IP stack will be used whenever. I'm a Windows user when I'm paid to be, yes. I am sorry. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpcesgCJ3DaA.pgp Description: PGP signature
Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
Matt Zimmerman [EMAIL PROTECTED] wrote:
I ran it through diffstat, and removed the files which are created entirely by
the patch, so these are the changes to common code:
I've had a look and it appears to be acceptable. Please file a bug
report against kernel and I'll probably include it when 2.4.23 is
released.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debian should not modify the kernels!
This thread has been going on for a while, and I think the general voice has been that security backports and other vital patches are totally alright for kernel-source. However, I think the general agreement is that feature backports are not okay. That's what kernel-patches are for. I would like to hear an official statement by Herbert on this. We should not let this thread extend to infinity, but come to conclusions and implement them in time for the Sarge release. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpnKBFruYtIm.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, 22 Sep 2003 22:04:15 +0200 martin f krafft [EMAIL PROTECTED] wrote: I'd appreciate if you would not quote me on a mailing list without my consent. Anyhow... also sprach Florian Weimer [EMAIL PROTECTED] [2003.09.22.2114 +0200]: It's a well accepted fact among kernel developers that vanilla kernel.org kernels should not be used by end users. Could you point me to some reference on this, please? Albeit rather advanced, I am an end user that uses the vanilla kernels, so I should know some reasons. The ptrace bug fix took two monthes to be fixed in a stable kernel. The arguement was that end users use a distro kernel that would pick up the fix, and if you used kernel.org, you would read the lists to get the fix (ie, you patch kernel.org, if that's what you run). Releases have been much more frequent since then... Thomas pgpMwEFYNodgL.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On 22-Sep-03, 14:14 (CDT), Florian Weimer [EMAIL PROTECTED] wrote: It's a well accepted fact among kernel developers that vanilla kernel.org kernels should not be used by end users. Debian has to patch the kernel, too. There isn't much choice. Agreed, but there's a significant difference between including bug fixes and de-facto required architecture-specific updates and including a completely new subsystem backported from 2.5 yet calling it 2.4. For $DIETY's sake, we keep ALSA as a separate patch/module, why is putting in IPSEC justified? Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Debian should not modify the kernels!
On Mon, Sep 22, 2003 at 09:31:49PM +1000, Herbert Xu wrote: George Danchev [EMAIL PROTECTED] wrote: it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is useless, leave to users to patch if they want) then all other kernel-patch-whatever packages will be fine. It is unacceptable for us to distribute kernels with known (security) bugs. sorry for the profane question, is IPsec related to any security issue in 2.4.2x kernels? i don't care about IPsec, i don't either know what it really is and i'm having problems with it. is there a way to throw away it without loose other bugs fixes? thanks dom -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Debian should not modify the kernels!
also sprach Eduard Bloch [EMAIL PROTECTED] [2003.09.22.1155 +0200]: And if you meant the kernel-source package, then please think twice before you request a such thing. Your idea would require dozens of versions of kernel-source-NUMBER-foo every time when I a small fix had to be applied. Why? No, it would require one kernel-source package which installs the kernel source, not the Debian-modified kernel source. Reality check please. grsec modifies the kernel so heavily that it will ALWAYS conflict with something when you modify the kernel a bit more that with trivial bugfixes. Yeah, but that something I can work around. I am not willing to port grsec to a new IP stack or other new features. There is your reality check. The same would happen if it conflicts with ANY of the 93 kernel-patches in the archive - there is no reason for rants on -devel. I am not arguing this. significantly modified; why aren't those modifications distributed as seperate kernel patches / debian packages in the same way grsec is? Martin can _simply_ create an alternative apply script which unpatches the Debian source when needed before applying the grsec patch. Quiet, transparent solution. So then what happens if a user falsely employs the Debian 2.4 kernel feature IPsec and one day decides to use GRsecurity? This is a bad suggestion. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpgWxxbANEjl.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Bernhard R. Link [EMAIL PROTECTED] [2003.09.22.1213 +0200]: Thus I see absolutely no reason, why I should want a debian-package with a unmodified source-tree. Because -- it may be on a CD and you cannot download 25+ Mb -- your kernel source is integrated with the Debian package management system and will be updated with security (!) updates when need be and possibly others. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpZ4mfXeoWbZ.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Martin Pitt [EMAIL PROTECTED] [2003.09.22.1343 +0200]: However, they might be useful to people using make-kpkg and patch packages to get the right dependencies and ease the download. Thus I would not vote to throw them out completely. make-kpkg and kernel-patches/modules work just fine with vanilla sources. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpsGL6HKYDg3.pgp Description: PGP signature
Re: Debian should not modify the kernels!
also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.22.1320 +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? it's a chunk of code that has almost nothing to do with the core kernel code You don't consider the IP stack to be core? Are you a Windows user? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgprI112XdBx4.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, Sep 22, 2003 at 08:03:50PM +0200, martin f krafft wrote: also sprach Martin Pitt [EMAIL PROTECTED] [2003.09.22.1343 +0200]: However, they might be useful to people using make-kpkg and patch packages to get the right dependencies and ease the download. Thus I would not vote to throw them out completely. make-kpkg and kernel-patches/modules work just fine with vanilla sources. Except with --initrd. -- - mdz
Re: Debian should not modify the kernels!
On Mon, Sep 22, 2003 at 07:52:40PM +0200, Domenico Andreoli wrote: sorry for the profane question, is IPsec related to any security issue in 2.4.2x kernels? i don't care about IPsec, i don't either know what it really is and i'm having problems with it. is there a way to throw away it without loose other bugs fixes? Profane question? Where is the profanity? Why did you get my hopes up? :) -- G. Branden Robinson|You should try building some of the Debian GNU/Linux |stuff in main that is [EMAIL PROTECTED] |modern...turning on -Wall is like http://people.debian.org/~branden/ |turning on the pain. -- James Troup signature.asc Description: Digital signature
Re: Debian should not modify the kernels!
Hi, Herbert Xu wrote:
George Danchev [EMAIL PROTECTED] wrote:
it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is useless,
leave to users to patch if they want) then all other kernel-patch-whatever
packages will be fine.
It is unacceptable for us to distribute kernels with known (security) bugs.
The current problem, which is IPsec 2.5 backported, hardly qualifies as a
known security bug. Fixing security bugs doesn't usually cause patch
conflicts anyway.
IMHO, backporting stuff to 2.4 should be handled much like security
fixes, i.e. minimally and with care. Again IMHO, I don't think IPsec-2.5
qualifies.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
If everybody knows such and such, then it ain't so, by at least ten
thousand to one.
-- Lazarus Long
Re: Debian should not modify the kernels!
I'd appreciate if you would not quote me on a mailing list without my consent. Anyhow... also sprach Florian Weimer [EMAIL PROTECTED] [2003.09.22.2114 +0200]: It's a well accepted fact among kernel developers that vanilla kernel.org kernels should not be used by end users. Could you point me to some reference on this, please? Albeit rather advanced, I am an end user that uses the vanilla kernels, so I should know some reasons. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgplwQDrelAzo.pgp Description: PGP signature
Re: Debian should not modify the kernels!
George Danchev wrote: On Monday 22 September 2003 14:20, Matthew Garrett wrote: It would be inappropriate to do it within a stable release, sure, but it is something that Debian do do in general. Then all kernel-source-x.y.z prepared like this kernel-source-2.4.22 2.4.22-1 will never be release-ready or candidates for Stable (so sad). Then why it has been introduced to official Debian archive? You've misunderstood me. It would be inappropriate to add backported features to a stable update. It's entirely appropriate to do so before the package enters stable, providing that this doesn't compromise the functionality of the package. In this case it's a chunk of code that has almost nothing to do with the core kernel code - it just This is very arguable. Have you apt-get source kernel-source-2.4.22 then looked at the patch ? Yes. so happens that in the pathological case of a kernel patch, there's some awkwardness. it is not a pathological case, this is how the patch program works: it reads the patch file (prepared with diff) and tries to find the relevent rows in files within the tree it is patchng, if these rows are missing or fuzzy then what do you expect the patch program to do, it simply can not replace them out ? it is not like a programmer to merge it manually and checks to ensure that there are no logical errors introduced during the merge. Additional kernel patches are not the norm, and are the only case where current policy causes problems. They're a pathological case. That's an indication that our kernel patching system should be rationalised, not that shipping modified kernels is wrong. No, that is an indication that kernel-source-x.y.x is moving target and you will always have issues paching it ... Of course it's a moving target. It's a large chunk of code that changes significantly between minor version numbers. The solution here is for developers to work together in order to work out which parts of the Debian patches are essential, and which are value added. The latter ought to be either easily strippable or added later, allowing users to customise things more easily. Do not get me wrong. I'm not against shipping modified kernels, but do not it Red Hat way having 2.6 stuff shipped with names like kernel-...-2.4... It is not 2.4.x then ... If I want such behaviour I'll run Red Hat... so please do not kill the only one and true/safest/sanest GNU/Linux harbor around ... e.g. Debian. And our SSH isn't 3.4p1 either. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
On Mon, Sep 22, 2003 at 09:31:49PM +1000, Herbert Xu wrote: George Danchev [EMAIL PROTECTED] wrote: it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is useless, leave to users to patch if they want) then all other kernel-patch-whatever packages will be fine. It is unacceptable for us to distribute kernels with known (security) bugs. Is there a particular reason we are distributing old kernels at all? I see the following in the archive: kernel-source-2.2.25 old - kernel-source-2.4.19-hppa old - kernel-source-2.4.19 old - kernel-source-2.4.20 old - kernel-source-2.4.21 kernel-source-2.4.22 old - kernel-source-2.5.69 old - kernel-source-2.6.0-test2 old - kernel-source-2.6.0-test4 A current kernel shouldn't have known security holes in most cases and if it does security fixes (ONLY) should be applied. I do recall the case where the kernel didn't have a root hole fixed for a while earlier this year, but that seemed to be caused by no one knowing how to fix the hole properly without breaking other things. A kernel that has no security fixes should be identical to upstream except for whatever happens to be in the debian dir. On a related note, it would be nice if stable could have updated kernels since it is somewhat difficult to install Debian on modern systems when the newest kernel in stable is 1.5 years old (2.4.18 Feb 25 2002). For my last three systems I have had to download knoppix and use debootstrap to install. A newbie would likely just give up. Chris BTW - linux-2.6.0-test5 was released Sept 8.
Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
David Z Maze [EMAIL PROTECTED] wrote:
...do you include *everything* that comes by you that meets these
criteria? Because from this it sounds like anything that has an
upstream that can be built as modules would be included. My
particular directed thought right now is a somewhat invasive patch
that updates the 2.4 kernels to use i2c-2.8, which would solve some
headaches for me (somewhat invasive, in that it also goes off and
modifies all of the other drivers that depend on i2c); if I were the
kernel maintainer, it'd trip a too different from kernel.org flag
for me, but it sounds like it does meet your four criteria here.
I'm afraid your patch fails the maintainence and the correctness checks.
It fails the maintainence because your upstream has had a bad track
record at getting patches merged, so there is a strong likelihood that
we'll have to pick up the pieces at some future point in time.
It fails the correctness check because it'll probably break the in-kernel
users of i2c.
The maintainence check is tougher than you think. For any patch of a
respectable size, unless it is clearly going to be merged into Linux
proper then it is likely to fail that check.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
Matt Zimmerman [EMAIL PROTECTED] wrote:
OK, these are very minimal criteria, and I think that probably many of the
kernel-patch packages in Debian would fit them. Where would you draw the
line?
Most of them fail the maintainence check.
Unless the patch is clearly going to be merged upstream, it is just too
unpredictable what the level of maintainence is going to be say in a year.
I currently patch my kernels with device-mapper, a few evms-related patches
and skas3. It would be very convenient if device-mapper and the evms
patches could be included in the the stock kernel; then users could use EVMS
or LVM2 in stock kernel images. This is especially useful in the installer
kernels.
Is the device-mapper completely modularised? If it is, then I have
no problems with including it.
For the other patches, please send them to me along with reasons why
you think they should be included.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
On Tue, Sep 23, 2003 at 08:08:07AM +1000, Herbert Xu wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: I currently patch my kernels with device-mapper, a few evms-related patches and skas3. It would be very convenient if device-mapper and the evms patches could be included in the the stock kernel; then users could use EVMS or LVM2 in stock kernel images. This is especially useful in the installer kernels. Is the device-mapper completely modularised? If it is, then I have no problems with including it. I'm not sure what completely means here. If it means doesn't touch common code, then of course device-mapper does not fit that description. Of course, then ipsec certainly does not either. Here is a diffstat: I ran it through diffstat, and removed the files which are created entirely by the patch, so these are the changes to common code: Documentation/Configure.help| 14 MAINTAINERS |7 arch/mips64/kernel/ioctl32.c| 17 arch/parisc/kernel/ioctl32.c| 17 arch/ppc64/kernel/ioctl32.c | 17 arch/s390x/kernel/ioctl32.c | 15 arch/sparc64/kernel/ioctl32.c | 17 arch/x86_64/ia32/ia32_ioctl.c | 17 drivers/md/Config.in|2 drivers/md/Makefile | 35 - drivers/md/lvm.c|9 fs/buffer.c | 29 fs/jbd/journal.c| 10 fs/reiserfs/super.c |2 fs/super.c | 138 include/linux/fs.h |5 include/linux/jbd.h |2 include/linux/vmalloc.h |1 kernel/ksyms.c |3 mm/Makefile |4 mm/filemap.c| 11 mm/vmalloc.c| 19 The only new object which is not part of the dm module is mm/mempool.c. As you are no doubt aware, device-mapper is maintained, and merged in 2.6.0. For the other patches, please send them to me along with reasons why you think they should be included. EVMS can work fine with only device-mapper, but it adds a few things which are in separate patches, mostly related to device-mapper. All of them are in the kernel-patch-evms package for your perusal, but I can send you copies if you like. These are entirely self-contained and modularized: evms-dm-bbr - a bad block relocation target for device-mapper evms-dm-sparse - a sparse device target for device-mapper This changes only one module, which is part of device-mapper: evms-dm-snapshot - updates to the snapshot target for device-mapper and these are fixes to common code to work better with evms/dm: evms-jfs - very tiny, adds a couple of calls to updateSuper in fs/jfs/super.c; I think this may be needed for snapshots of JFS filesystems evms-md-multipath - fixes to the md multipath module I don't use JFS or MD multipath, so I can't really speak to these last two patches. -- - mdz
Re: Debian should not modify the kernels!
On Sunday 21 September 2003 14:41, Herbert Xu wrote: martin f krafft [EMAIL PROTECTED] 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: Yes, but it is not available in a finest way possible. 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 This is misleading by the way of kernel source tree you provide. kernel-source-2.4.22 must contain just plain vanilla kernel sources + debian/ directory. Then if I want your backported patches (or anything else) I'll apt-get install kernel-patch-debian-2.4.22 and patch (NOTE: not to *unpatch*) the 2.4.22 source tree. * The IPSEC backport can be easily reversed by unapplying the patches given in the README.Debian file. it is better to provide in README.Debian patches (made as debian pacvkages) you suggest to be applied not to unapplied. * 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. I agree it is nice to have kernel patches as debian packages, but if the name of kernel source tree is kernel-source-2.4.22 it should provide 2.4.22 vanilla sources otherwise name it kernel-source-2.4.22-vendor-debian. So either get the people who're complaining to you to unapply the IPSEC patch, or fix your patch instead. it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is useless, leave to users to patch if they want) then all other kernel-patch-whatever packages will be fine. -- pub 4096R/0E4BD0AB 2003-03-18 keyserver.bu.edu 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: Debian should not modify the kernels!
On Sunday 21 September 2003 16:04, Josip Rodin wrote: On Sun, Sep 21, 2003 at 02:44:03PM +0200, martin f krafft wrote: * The vanilla kernel source is readily available: I don't consider this readily available. It's faster to just download it from kernel.org. Frankly, I doubt that. Debian mirror network seems better to me. I am biased, but still. :) because debian's readily available's and to save bandwidth when updating I use some of the followings to get vanillas, then I use the awesome make-kpkg: Subversion (http://svnbook.red-bean.com/) === Trunk (main/latest) - 2.4, 2.5, 2.6 -- # svn co svn://kernel.bkbits.net/linux-2.4/trunk linux-2.4-trunk # svn co svn://kernel.bkbits.net/linux-2.5/trunk linux-2.5-trunk # svn co svn://kernel.bkbits.net/linux-2.6/trunk linux-2.6-trunk Revisions - 2.4, 2.5 - # svn co svn://kernel.bkbits.net/linux-2.4/tags/v2.4.X linux-2.4.X # svn co svn://kernel.bkbits.net/linux-2.5/tags/v2.5.X linux-2.5.X # cd kernel-src-dir # svn log ChangeLog CVS (http://www.cvshome.org/) === Trunk (main/latest) - 2.4, 2.5 -- # cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs co linux-2.4-trunk # cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs co linux-2.5-trunk -- pub 4096R/0E4BD0AB 2003-03-18 keyserver.bu.edu 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: Debian should not modify the kernels!
Hi! Am 2003-09-21 13:09 +0200 schrieb martin f krafft: If I install kernel-source-2.4.21, I want the 2.4.21 kernel source, I don't want the 2.4.21 kernel source with 2.5's IPsec stack patched in and hundreds of little fixes. I fully agree with this. Speaking as an user, it is perfectly okay and desirable to have a _default_ installation Debian kernel which is patched (security, ALSA, whatever). Those users who don't care or don't know about kernel compiling issues will rest in peace and will benefit from updated packages from time to time. But as soon as I plan to compile a kernel by myself, I expect that the content delivers what its label promises! Thats a matter of principle, not a matter of measure. yeah, but look at distribution xyz, they do it even worse is IMHO not the best approach, Debian should not clone other's faults but try to be better. Thus, I propose: - a package kernel-debian-default (or similar), which is patched at the maintainer's will and regularly updated with new features and security patches. This is for users that don't compile their own kernels, thus the package should not contain the source code. - packages kernel-x.y.z which contains an _unmodified_ upstream kernel source; patches can be applied to it by installing kernel-patch-x.y.z-patchname (the way it currently is intended) Thanks and have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED] pgprqaPMRehw8.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Sun, Sep 21, 2003 at 05:05:46PM +0200, martin f krafft wrote: also sprach Mark Brown [EMAIL PROTECTED] [2003.09.21.1644 +0200]: effects (better hardware support, more features, better performance or what have we) are generally seen to be worthwhile. ... in addition to possibly more bugs and the inability of interaction with the kernel and the rest of the world. linux-kernel Well, yes. This is one reason for not just slinging in any old patches and being willing to provide support for the kernel you ship. Things like 2.5 backports are reasonably safe even if they introduce ABI changes, for example - the kernel maintainers have made some commitment to providing that ABI already. I am not saying that all this shouldn't happen. I am just saying it shouldn't be the default. Debian is about choice, isn't it? Well, opt-in choice it should be! Well, what you seem to want is to have the kernel source avaliable in a format that makes packaging kernel patches easy. That seems like a different issue to me. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Debian should not modify the kernels!
On Sun, Sep 21, 2003 at 12:00:05PM -0700, Erik Steffl wrote: if I get kernel 2.4.22 as a debian package I expect kernel 2.4.22 as a debian package, not something else... any debian specific changes should result in kernel name change, that's what's expected in kernel world (when I get ac kernel I get 2.4.22-ac3) Me too - if we have to have significantly modified kernels, they should be labelled as being such. If the issue here is the grsec patch distributed as a debian package cannot cleanly apply to the debian kernel sources because they have been significantly modified; why aren't those modifications distributed as seperate kernel patches / debian packages in the same way grsec is? -- Jon Dowland http://jon.dowland.name/
Re: Debian should not modify the kernels!
* Martin Pitt [EMAIL PROTECTED] [030922 10:40]: Speaking as an user, it is perfectly okay and desirable to have a _default_ installation Debian kernel which is patched (security, ALSA, whatever). Those users who don't care or don't know about kernel compiling issues will rest in peace and will benefit from updated packages from time to time. But as soon as I plan to compile a kernel by myself, I expect that the content delivers what its label promises! Thats a matter of principle, not a matter of measure. yeah, but look at distribution xyz, they do it even worse is IMHO not the best approach, Debian should not clone other's faults but try to be better. Speaking as a user, too, I want something I can compile a kernel from. I'm no kernel hacker and do not intend to become one. Thus I see absolutely no reason, why I should want a debian-package with a unmodified source-tree. Escecially as an unmodified source-tree is in my experience almost only useful for i386. (Perhaps getting better in the last time, but anything not a debian kernel used to be even a larger nightmare than the debian-kernels). So your complain reduces in my eyes to an incomplete label. I personally think not having the term linux in it more of an issue than having -debian in it... Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Debian should not modify the kernels!
Hi! Am 2003-09-22 12:13 +0200 schrieb Bernhard R. Link: Speaking as a user, too, I want something I can compile a kernel from. I'm no kernel hacker and do not intend to become one. Thus I see absolutely no reason, why I should want a debian-package with a unmodified source-tree. I agree. I never use Debian kernel packages anyway and even if they were unpatched, they were only of little use to _me_ (apart from problems like faster mirror/cd distributions). However, they might be useful to people using make-kpkg and patch packages to get the right dependencies and ease the download. Thus I would not vote to throw them out completely. So your complain reduces in my eyes to an incomplete label. Partly. But it also extends to the technical level: When shipping kernel-patch packages, then Debian should have a common codebase to diff against; the straightforward choice is IMHO the pristine upstream version, shipped in a kernel package. Escecially as an unmodified source-tree is in my experience almost only useful for i386. I don't know much about other arches, but patching the source tree is certainly arch independent. The i386 won't help if a grsecurity patch does not apply because the source is messed up and the user does not know about it (since it _claimed_ to be the original code). Platform-specific patches should certainly go into the Debian default installation kernel, but that is a completely different issue. Have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
hi, On Mon, Sep 22, 2003 at 12:13:51PM +0200, Bernhard R. Link wrote: Speaking as a user, too, I want something I can compile a kernel from. I'm no kernel hacker and do not intend to become one. Thus I see absolutely no reason, why I should want a debian-package with a unmodified source-tree. Escecially as an unmodified source-tree is in my experience almost only useful for i386. (Perhaps getting better in the last time, but anything not a debian kernel used to be even a larger nightmare than the debian-kernels). i have to say, that an vanilla kernel-source in Debian would be nice, but i never had Problems with compiling the source Packages which are in the Distribution now. I think the Kernel-Source-Package Maintainers know what they are doin, and if the Patches are limited to Security Fixes and things which make the Kernel more stable and secure i don't have Problems with the current situation. People which do not want to take the Debian Sources because, the're patched, have the possibility to use the Kernel Sources from kernel.org, and use make-kpkg to create an Debian Package. bye, - michael
Re: Debian should not modify the kernels!
#include hallo.h * George Danchev [Mon, Sep 22 2003, 10:40:10AM]: This is misleading by the way of kernel source tree you provide. kernel-source-2.4.22 must contain just plain vanilla kernel sources + debian/ directory. Then if I want your backported patches (or anything else) I'll apt-get install kernel-patch-debian-2.4.22 and patch (NOTE: not to *unpatch*) the 2.4.22 source tree. Let's create a package called linux-2.4.22 or linux-2.4.22-pure-vanilla-source-for-you-to-patch with a script which does exactly this. MfG, Eduard. -- Das Unglück der Weiber ist, daß sie nicht imstande sind, Männer so keck zu verachten als Weiber. -- Jean Paul
Re: Debian should not modify the kernels!
#include hallo.h * Jonathan Dowland [Mon, Sep 22 2003, 10:05:13AM]: if I get kernel 2.4.22 as a debian package I expect kernel 2.4.22 as a debian package, not something else... any debian specific changes should result in kernel name change, that's what's expected in kernel world (when I get ac kernel I get 2.4.22-ac3) Me too - if we have to have significantly modified kernels, they should be labelled as being such. They are - look at the last part of the kernel-image-KVERS image. And if you meant the kernel-source package, then please think twice before you request a such thing. Your idea would require dozens of versions of kernel-source-NUMBER-foo every time when I a small fix had to be applied. If you prefer to sponsor new harddisks for all Debian mirrors (because the archive size explodes), please do. If the issue here is the grsec patch distributed as a debian package cannot cleanly apply to the debian kernel sources because they have been Reality check please. grsec modifies the kernel so heavily that it will ALWAYS conflict with something when you modify the kernel a bit more that with trivial bugfixes. The same would happen if it conflicts with ANY of the 93 kernel-patches in the archive - there is no reason for rants on -devel. significantly modified; why aren't those modifications distributed as seperate kernel patches / debian packages in the same way grsec is? Martin can _simply_ create an alternative apply script which unpatches the Debian source when needed before applying the grsec patch. Quiet, transparent solution. MfG, Eduard. -- Als Passwort nahm er seinen Namen, bis eines Nachts die Hacker kamen.
Re: Debian should not modify the kernels!
On Monday 22 September 2003 13:13, Bernhard R. Link wrote: * Martin Pitt [EMAIL PROTECTED] [030922 10:40]: Speaking as an user, it is perfectly okay and desirable to have a _default_ installation Debian kernel which is patched (security, ALSA, whatever). Those users who don't care or don't know about kernel compiling issues will rest in peace and will benefit from updated packages from time to time. But as soon as I plan to compile a kernel by myself, I expect that the content delivers what its label promises! Thats a matter of principle, not a matter of measure. yeah, but look at distribution xyz, they do it even worse is IMHO not the best approach, Debian should not clone other's faults but try to be better. Speaking as a user, too, I want something I can compile a kernel from. I'm afraid that more people here speak as maintainers and the point is about what kind(s) of kernel-source packages Debian provides... it is not just something you compile kernel images from... it has reasonable names following the content it provides;-) I'm no kernel hacker and do not intend to become one. Thus I see absolutely no reason, why I should want a debian-package with a unmodified source-tree. Let me point out that Debian has always provided upstream (unmodified/ pristine) kernel source by the means of kernel-source-x.y.z packages and kernel-patch-whatever ... and so on ... Now with kernel-source-2.4.22 the situation has been changed... Please read /usr/share/doc/kernel-source-2.4.22/README.Debian.gz for more. Nice patch has been applied to vanilla sources (note: provided by kernel-source-2.4.22) instead just being distributed as regular kernel-patch-ipsec-or-so ... Note that this patch doesn't fix security issue(s), but instead adds a feature. It is all fine, but let the user decides if s/he wants to have it applied against vanilla sources and do it his/herself... Otherwise you convey debian users to kernel.org or bkbits.net to get pristine sources and then apply patches if any. Escecially as an unmodified source-tree is in my experience almost only useful for i386. (Perhaps getting better Not true ;-) So called by you unmodified has all architecture-specific code inside. Get a kernel from kernel.org or svn from bkbits.net and cd arch/ in the last time, but anything not a debian kernel used to be even a larger nightmare than the debian-kernels). Now you have a real nightmare with kernel-source-2.4.22 (named to bring the upstream 2.4.22, but instead patched and that was documented of course, but that is not the Debian way of dealing with kernels) breaking bunch of usefull kernel-patch-whatever. Again, if the aboves continue to happen, then most likely bunch of users will get their pristine kernel sources not from debian archive (which is sad) and patch on-their-demand. Reasonable names following the spirit of debian imho are: kernel-source-2.4.22 (strict vanilla) kernel-patch-debian-2.4.22 (patch applied by Debian, Hurray ! yet another vendor specific kernel source tree ;-) kernel-patch-other-features-version (other usefull patches) -- pub 4096R/0E4BD0AB 2003-03-18 keyserver.bu.edu 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: Debian should not modify the kernels!
Hi! Am 2003-09-22 11:55 +0200 schrieb Eduard Bloch: significantly modified; why aren't those modifications distributed as seperate kernel patches / debian packages in the same way grsec is? Martin can _simply_ create an alternative apply script which unpatches the Debian source when needed before applying the grsec patch. Quiet, transparent solution. When Debian claims to ship kernels with security patches, then another Debian package should not silently remove them; that would be very dangerous (and IMHO silly). I could live with this solution if such an unpatch is verbosely announced to the user (let's say, with a debconf note of priority high). Have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
martin f krafft wrote: also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.21.1= 614 +0200]: Should we stop shipping security fixes backported from development code? It always depends, doesn't it? We are backporting *security* fixes to packages, but we take care not to introduce new features. I don't oppose some small modifications to the kernel, fixes and security backports, but including a 2.5 IPsec stack in 2.4.21 is kinda not in accordance with that policy, now is it? 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. -- Matthew Garrett | [EMAIL PROTECTED]
