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
> > off
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 s
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.
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 r
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!
..
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, j
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
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
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 e
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
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
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 feat
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.
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
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
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
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
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
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 posi
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
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
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
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 ma
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 co
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 is
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
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
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
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!
.''`. mar
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
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
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
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!
.''`.
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 t
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
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.
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 wh
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-*. T
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
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?
> R
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
* 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.
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 fe
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
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
> differenc
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
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 neces
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 achiev
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
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..
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 i
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, a
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
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
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 grs
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 maintai
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 acc
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 alr
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
>> a
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
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. Th
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.
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.
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
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
>> > packa
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 t
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
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
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 - li
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 c
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
ver
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 differenc
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 develop
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
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 up
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 inva
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-
> > packages will be fine.
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 b
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 m
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-
>> packages will be fine.
>
> It is unacceptable for us to distribute kerne
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 with
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
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
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 j
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 pack
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
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-
> > packages will be fine.
On Mon, 22 Sep 2003, Martin Pitt wrote:
> 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 use
On Mon, 22 Sep 2003, Eduard Bloch wrote:
> 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 tim
On Sun, 21 Sep 2003, Martin Michlmayr wrote:
> * martin f krafft <[EMAIL PROTECTED]> [2003-09-21 14:44]:
> > What you distribute as 2.4.22 is not 2.4.22.
>
> So what? Most packages in Debian devate from upstream in one way or
> another. That's the added value we provide. I'm happy that Herbert
On Sun, Sep 21, 2003 at 01:09:08PM +0200, martin f krafft 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 th
George Danchev wrote:
>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- ... and so on ... Now with kernel-source-2.4.22 the
>situation has been changed...
Nonsense. As a trivial counte
On Mon, Sep 22, 2003 at 09:30:28PM +1000, Herbert Xu wrote:
> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> >
> > So, I'm curious why you chose to make it a part of the Debian kernel source,
> > rather than a separate patch (kernel-patch-ipsec or such).
>
> Well the reason for it to be in the defa
On Mon, Sep 22, 2003 at 04:04:22PM +0300, George Danchev wrote:
> 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- ... and so on ... Now with kernel-source-2.4.22 the
> situation has
Herbert Xu <[EMAIL PROTECTED]> writes:
> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>>
>> So, I'm curious why you chose to make it a part of the Debian
>> kernel source, rather than a separate patch (kernel-patch-ipsec or
>> such).
>
> Well the reason for it to be in the default kernel-source is s
On Monday 22 September 2003 14:20, Matthew Garrett wrote:
> 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
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-
> packages will be fine.
It is unacceptable for us to distribute kernels with known (security) bugs.
--
Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>
> So, I'm curious why you chose to make it a part of the Debian kernel source,
> rather than a separate patch (kernel-patch-ipsec or such).
Well the reason for it to be in the default kernel-source is simple:
The patch should be used on all default Deb
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 ne
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 wh
1 - 100 of 132 matches
Mail list logo
