Release of 2.4.21

Release of 2.4.21

[Adrian Knoth]

Hi,

how about releasing 2.4.21 with the ptrace()-fix applied immediately
like it has been done with 2.2.25?

I think it's a serious bug and therefore it's time for a security-update.

If you think of ISC bind, PHP, sendmail or other software a new release
follows right after the availability of the patch. I'd like Linux
(and glibc as well) to do the same. You cannot call 2.4.20 a stable kernel
with such a bug, so as a leader of the 2.4.x-series you cannot call the
whole branch "stable".

World needs to update, best way to enforce is by a new release.

-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Das letzte Schoene, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

Re: Release of 2.4.21

[Sebastian D.B. Krause]

On 3487 September 1993, Adrian Knoth wrote:
> how about releasing 2.4.21 with the ptrace()-fix applied immediately
> like it has been done with 2.2.25?
>
> I think it's a serious bug and therefore it's time for a security-update.

I think the best way is to release a 2.4.21 kernel with only the
most important fixes (e.g. ptrace, ext3) and no new features. All
new featues which need more testing and are now in 2.4.21-pre could
then go to 2.4.22-pre for more testing (as Alan did with
2.2.25-pre1). This would be a way to react to important bugs very
fast without a lack of enough testing which is just impossible with
the current release scheme. It's just too dangerous to call 2.4.20
"stable" and wait another few month for 2.4.21.

Sebastian

Re: Release of 2.4.21

[Jeff Garzik]

On Thu, Mar 20, 2003 at 09:21:01PM +0100, Sebastian D.B. Krause wrote:
> On 3487 September 1993, Adrian Knoth wrote:
> > how about releasing 2.4.21 with the ptrace()-fix applied immediately
> > like it has been done with 2.2.25?
> >
> > I think it's a serious bug and therefore it's time for a security-update.
> 
> I think the best way is to release a 2.4.21 kernel with only the
> most important fixes (e.g. ptrace, ext3) and no new features. All
> new featues which need more testing and are now in 2.4.21-pre could
> then go to 2.4.22-pre for more testing (as Alan did with

Something vaguely like this has been suggested, which I think is a good
idea:

For critical fixes, release a 2.4.20.1, 2.4.20.2, etc.  Don't disrupt
the 2.4.21-pre cycle, that would be less productive than just patching
2.4.20 and rolling a separate release off of that.

	Jeff

Re: Release of 2.4.21

[Christoph Hellwig]

On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> For critical fixes, release a 2.4.20.1, 2.4.20.2, etc.  Don't disrupt
> the 2.4.21-pre cycle, that would be less productive than just patching
> 2.4.20 and rolling a separate release off of that.

I think the naming is illogical.  If there's a bugfix-only release
it whould have normal incremental numbers.  So if marcelo want's
it he should clone a tree of at 2.4.20, apply the essential patches
and bump the version number in the normal 2.4 tree to 2.4.22-pre1

Re: Release of 2.4.21

[Jeff Garzik]

On Thu, Mar 20, 2003 at 08:42:18PM +0000, Christoph Hellwig wrote:
> On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc.  Don't disrupt
> > the 2.4.21-pre cycle, that would be less productive than just patching
> > 2.4.20 and rolling a separate release off of that.
> 
> I think the naming is illogical.  If there's a bugfix-only release

Many, many companies seem to find it logical.  If you want to squeeze
a version in between "1" and "2".

Further, other kernel hackers suggested the 2.4.20.N sequence,
I simply agreed with it.  So it's not only me who thinks this way :)


> it whould have normal incremental numbers.  So if marcelo want's
> it he should clone a tree of at 2.4.20, apply the essential patches
> and bump the version number in the normal 2.4 tree to 2.4.22-pre1

Human nature says that will drag out the -pre tree ad infinitum.
Suppose a 2.4.21 is released today, with 2.4.20 + bug fixes.  Now,
tomorrow, another "critical bug" comes out, and then the -pre tree
becomes 2.4.23-pre.  Add another critical bug, and I hope you see
the continual delay of -pre happens here...

The basic logic is "do not disrupt current plans.  Do something
_in addition to_ current plans."

	Jeff

Re: Release of 2.4.21

[David Lang]

hopefully we won't have a steady stream of critical bugs. if we do we need
to stop new development and find out where we are going wrong.

after all this isn't microsoft.

one advantage of useing a good version control system is that it should be
very easy to make a minor update to 2.4.20 to produce 2.4.21 without it
being a major disruption to things and then continue with the existing
development. from what I understand about bk it should make it even
easier.

I don't like going to 4 part version numbers. if this was a marketing
driven company that had promised features in 2.4.21 and they aren't ready
but a new version is needed then we would have a reason to do a 2.4.20.1
so that we don't have to deal with broken promises, but sine we aren't in
that situation I don't see why the 2.4.20.N is needed.

Every other time there has been a critical bug it was fixed in the next
normal release number (or if it's critical enough it was handled  by
rushing a version with just that fix like happened with 2.2)

David Lang


On Thu, 20 Mar 2003, Jeff Garzik wrote:

> Date: Thu, 20 Mar 2003 15:53:38 -0500
> From: Jeff Garzik <jgarzik@pobox.com>
> To: Christoph Hellwig <hch@infradead.org>, linux-kernel@vger.kernel.org,
>      marcelo@conectiva.com.br
> Subject: Re: Release of 2.4.21
>
> On Thu, Mar 20, 2003 at 08:42:18PM +0000, Christoph Hellwig wrote:
> > On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> > > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc.  Don't disrupt
> > > the 2.4.21-pre cycle, that would be less productive than just patching
> > > 2.4.20 and rolling a separate release off of that.
> >
> > I think the naming is illogical.  If there's a bugfix-only release
>
> Many, many companies seem to find it logical.  If you want to squeeze
> a version in between "1" and "2".
>
> Further, other kernel hackers suggested the 2.4.20.N sequence,
> I simply agreed with it.  So it's not only me who thinks this way :)
>
>
> > it whould have normal incremental numbers.  So if marcelo want's
> > it he should clone a tree of at 2.4.20, apply the essential patches
> > and bump the version number in the normal 2.4 tree to 2.4.22-pre1
>
> Human nature says that will drag out the -pre tree ad infinitum.
> Suppose a 2.4.21 is released today, with 2.4.20 + bug fixes.  Now,
> tomorrow, another "critical bug" comes out, and then the -pre tree
> becomes 2.4.23-pre.  Add another critical bug, and I hope you see
> the continual delay of -pre happens here...
>
> The basic logic is "do not disrupt current plans.  Do something
> _in addition to_ current plans."
>
> 	Jeff
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Release of 2.4.21

[Andrew Morton]

Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc.  Don't disrupt
> > the 2.4.21-pre cycle, that would be less productive than just patching
> > 2.4.20 and rolling a separate release off of that.
> 
> I think the naming is illogical.  If there's a bugfix-only release
> it whould have normal incremental numbers.  So if marcelo want's
> it he should clone a tree of at 2.4.20, apply the essential patches
> and bump the version number in the normal 2.4 tree to 2.4.22-pre1

No point in making things too complex.  2.4.20-post1 is something people can
easily understand.

I needed that for the ext3 problems which popped up shortly after 2.4.20 was
released - I was reduced to asking people to download fixes from my web page.

And having a -post stream may allow us to be a bit more adventurous in the
-pre stream.

Re: Release of 2.4.21

[John Bradford]

> > > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc.  Don't disrupt
> > > the 2.4.21-pre cycle, that would be less productive than just patching
> > > 2.4.20 and rolling a separate release off of that.
> > 
> > I think the naming is illogical.  If there's a bugfix-only release
> > it whould have normal incremental numbers.  So if marcelo want's
> > it he should clone a tree of at 2.4.20, apply the essential patches
> > and bump the version number in the normal 2.4 tree to 2.4.22-pre1
> 
> No point in making things too complex.  2.4.20-post1 is something people can
> easily understand.
> 
> I needed that for the ext3 problems which popped up shortly after 2.4.20 was
> released - I was reduced to asking people to download fixes from my web page.
> 
> And having a -post stream may allow us to be a bit more adventurous in the
> -pre stream.

Why can't we just make all releases smaller and more frequent?

Why do we need 2.4.x-pre at all, anyway - why can't we just test
things in the -[a-z][a-z] trees, and _start_ with -rc1?

Why can't we just do bugfixes for 2.4, and speed up 2.5 development?

John.

Re: Release of 2.4.21

[Samuel Flory]

John Bradford wrote:

>>>>For critical fixes, release a 2.4.20.1, 2.4.20.2, etc.  Don't disrupt
>>>>the 2.4.21-pre cycle, that would be less productive than just patching
>>>>2.4.20 and rolling a separate release off of that.
>>>>        
>>>>
>>>I think the naming is illogical.  If there's a bugfix-only release
>>>it whould have normal incremental numbers.  So if marcelo want's
>>>it he should clone a tree of at 2.4.20, apply the essential patches
>>>and bump the version number in the normal 2.4 tree to 2.4.22-pre1
>>>      
>>>
>>No point in making things too complex.  2.4.20-post1 is something people can
>>easily understand.
>>
>>I needed that for the ext3 problems which popped up shortly after 2.4.20 was
>>released - I was reduced to asking people to download fixes from my web page.
>>
>>And having a -post stream may allow us to be a bit more adventurous in the
>>-pre stream.
>>    
>>
>
>Why can't we just make all releases smaller and more frequent?
>
>Why do we need 2.4.x-pre at all, anyway - why can't we just test
>things in the -[a-z][a-z] trees, and _start_ with -rc1?
>
>Why can't we just do bugfixes for 2.4, and speed up 2.5 development?
>
>  
>

  That would imply some changes could take place in a short cycle.  This 
is not true for things like major ide subsystem updates.

-- 
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Re: Release of 2.4.21

[John Bradford]

> >>>>For critical fixes, release a 2.4.20.1, 2.4.20.2, etc.  Don't disrupt
> >>>>the 2.4.21-pre cycle, that would be less productive than just patching
> >>>>2.4.20 and rolling a separate release off of that.
> >>>>        
> >>>>
> >>>I think the naming is illogical.  If there's a bugfix-only release
> >>>it whould have normal incremental numbers.  So if marcelo want's
> >>>it he should clone a tree of at 2.4.20, apply the essential patches
> >>>and bump the version number in the normal 2.4 tree to 2.4.22-pre1
> >>>      
> >>>
> >>No point in making things too complex.  2.4.20-post1 is something people can
> >>easily understand.
> >>
> >>I needed that for the ext3 problems which popped up shortly after 2.4.20 was
> >>released - I was reduced to asking people to download fixes from my web page.
> >>
> >>And having a -post stream may allow us to be a bit more adventurous in the
> >>-pre stream.
> >>    
> >>
> >
> >Why can't we just make all releases smaller and more frequent?
> >
> >Why do we need 2.4.x-pre at all, anyway - why can't we just test
> >things in the -[a-z][a-z] trees, and _start_ with -rc1?
> >
> >Why can't we just do bugfixes for 2.4, and speed up 2.5 development?
> >
> >  
> >
> 
>   That would imply some changes could take place in a short cycle.  This 
> is not true for things like major ide subsystem updates.

We should not have major updates like that as a regular occurance in
the stable kernel series.  If they are necessary, we could break with
the small, frequent updates, and go back to what we have now.

Why can't we basically have two modes of working:

* When nothing major is being re-written:

Small, frequent updates.  -pre and -rc version numbering used to
indicate kernels which haven't had much testing.  Larger updates
existing in -[a-z][a-z] trees.


* When an update to a core subsystem is in progress

Larger, less frequent updates.  -pre and -rc versions getting more
testing, and -[a-z][a-z] trees for very experimental code.


I know there are frequently suggestions about how to organise kernel
development, and they are usually ignored, because we generally don't
like to work however we want to, but this suggestion is just common
sense.  When nothing much is going on, release smaller changes to get
a lot of testing of the same codebase.  When major work is going on,
separate out the minor updates to give people flexibility in testing.

John.

Re: Release of 2.4.21

[Bernd Petrovitsch]

John Bradford <john@grabjohn.com> wrote:
>>Why can't we just make all releases smaller and more frequent?
>
>Why do we need 2.4.x-pre at all, anyway - why can't we just test
>things in the -[a-z][a-z] trees, and _start_ with -rc1?
>
>Why can't we just do bugfixes for 2.4, and speed up 2.5 development?

Because 2.4 is used on (real) production systems - even my desktop PC
on my workplace is considered a production system - which (at least)
should run and therefore trying 2.5 is not an option (and no, no way).
And then it takes 1.5 years for the next stable kernel release which 
implies that quite new hardware (without an existing driver) cannot be
used for any production-like system.
IOW you would just loose a lot real use and testing of backported 
stuff and new hardware drivers.
And no, I don't think that someone wants that.

	Bernd

-- 
Bernd Petrovitsch                              Email : bernd@gams.at
g.a.m.s gmbh                                  Fax : +43 1 205255-900
Prinz-Eugen-Straße 8                    A-1040 Vienna/Austria/Europe
                     LUGA : http://www.luga.at

Re: Release of 2.4.21

[John Bradford]

> >>Why can't we just make all releases smaller and more frequent?
> >
> >Why do we need 2.4.x-pre at all, anyway - why can't we just test
> >things in the -[a-z][a-z] trees, and _start_ with -rc1?
> >
> >Why can't we just do bugfixes for 2.4, and speed up 2.5 development?
> 
> Because 2.4 is used on (real) production systems - even my desktop PC
> on my workplace is considered a production system - which (at least)
> should run and therefore trying 2.5 is not an option (and no, no way).
> And then it takes 1.5 years for the next stable kernel release which 
> implies that quite new hardware (without an existing driver) cannot be
> used for any production-like system.

I would include support for new chipsets in with bugfixes.

> IOW you would just loose a lot real use and testing of backported 
> stuff and new hardware drivers.

If nobody tests 2.5.x on a specific piece of hardware, 2.6.0 will be
released without being tested on that piece of hardware.

Incrementing the version number from 2.5.$bignum to 2.6.0 does _not_
magically fix all the bugs in it.

> And no, I don't think that someone wants that.

Production systems should be backed up.  No question about that.

Unless the system has to run 24/7, which a desktop machine usually
doesn't have to, I don't see why testing 2.5 on it isn't a
possibility.

John.

Re: Release of 2.4.21

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

Am Fre, 2003-03-21 um 10.23 schrieb John Bradford:

> Unless the system has to run 24/7, which a desktop machine usually
> doesn't have to, I don't see why testing 2.5 on it isn't a
> possibility.

Because desktop systems usually don't feature the notion of a testbed,
read an environment in which dangerous changes can be tested without
severe loss of important data.

I would never ever boot a 2.5.x kernel on my notebook or on any other 
machines without preparing a different harddrive for instance, YMMV
though.

-- 
Servus,
       Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Release of 2.4.21

[John Bradford]

> > Unless the system has to run 24/7, which a desktop machine usually
> > doesn't have to, I don't see why testing 2.5 on it isn't a
> > possibility.
> 
> Because desktop systems usually don't feature the notion of a testbed,
> read an environment in which dangerous changes can be tested without
> severe loss of important data.

So why did you trim the part of my quote that said that production
systems should always be backed up anyway?

> I would never ever boot a 2.5.x kernel on my notebook or on any other=20
> machines without preparing a different harddrive for instance, YMMV
> though.

It's not exactly much work to put a different disk in a machine.  With
a notebook, it might be 30-45 minutes work dismantling it, but on a
typical desktop, about 2 minutes, and on a rackmount server, probably
60 seconds.

John.

Re: Release of 2.4.21

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

Am Sam, 2003-03-22 um 09.27 schrieb John Bradford:

> So why did you trim the part of my quote that said that production
> systems should always be backed up anyway?

You consider normal desktop systems "production system"? Interesting...
The best on can hope for a desktop system is a regular becakup of
important work files to CD-R; we're more talking about a sector-wise
harddisk backup here which is not even common for server systems (no,
I'm not talking about RAID here) let alone Joe users system. 

For instance I do have a RAID and a regular rsync backup on my
production system here. That's still not enough for trying development
kernels on real data which might fry the filesystem because it'd be
fried on the mirrored harddrives at the same time and the rsynced copy
is not enough to fully recover the system.

> It's not exactly much work to put a different disk in a machine.

Yeah, though not something Joe user could do. And honestly this is not
something someone would do "just for fun", because it's still a lot of
trouble for a minor intent.

> With a notebook, it might be 30-45 minutes work dismantling it,

You certainly must be kidding. Dismantling my PowerBook is hardly
possible at all without killing it and the harddrive is quite hard to
replace. This is more like a 2h work and something I'd rather do once
in its lifetime for the sake of a bigger harddrive instead of trying
a development kernel.

>  but on a typical desktop, about 2 minutes, and on a rackmount server, probably
> 60 seconds.

Right. Let's see. It took me about 20 minutes to swap the CPU in this
"desktop" machine here, 15 minutes of that were used to dismantle the
system, pull the mounted motherboard (with all PCI cards in the slots,
my case luckily allows for that) and reassemble those parts. This action
is necessary to get to the right hand side screws which fasten the
harddrive.

It's not even realistic to assume that simply opening the case, and
reconnecting a loosely hanging around harddrive will just take 2
minutes.

-- 
Servus,
       Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Release of 2.4.21

[Alan Cox]

On Thu, 2003-03-20 at 19:56, Adrian Knoth wrote:
> (and glibc as well) to do the same. You cannot call 2.4.20 a stable kernel
> with such a bug, so as a leader of the 2.4.x-series you cannot call the
> whole branch "stable".
> 
> World needs to update, best way to enforce is by a new release.

The vendors have released updated kernels. Whats the problem ?

Re: Release of 2.4.21

[David Lang]

if official kernels were being released more rapidly then they are it
wouldn't be much of a problem (I can wait a week or two for this with no
problem) but it's currently several months between releases, and since
there are so many changes there is the potential that a new kernel could
be worse then what you are running.

yes I could download a patch and fix the kernel that way, but while I
understand how simple that is I can already hear the crys from management
about haphazardly patching things that then get put into production.

and as for the vendor kernels, I don't use them becouse they all make a
ton of changes that I don't want to deal with.

the stable kernel releases are a vendor for this situation and this
'vendor' has chosen to consider this bug not critical (along with a couple
others) which is a decision being questioned by folks.

David Lang


 On 21 Mar 2003, Alan Cox wrote:

> Date: 21 Mar 2003 01:01:34 +0000
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: Adrian Knoth <adi@drcomp.erfurt.thur.de>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: Release of 2.4.21
>
> On Thu, 2003-03-20 at 19:56, Adrian Knoth wrote:
> > (and glibc as well) to do the same. You cannot call 2.4.20 a stable kernel
> > with such a bug, so as a leader of the 2.4.x-series you cannot call the
> > whole branch "stable".
> >
> > World needs to update, best way to enforce is by a new release.
>
> The vendors have released updated kernels. Whats the problem ?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Release of 2.4.21

[Florian Weimer]

krause@sdbk.de (Sebastian D.B. Krause) writes:

> I think the best way is to release a 2.4.21 kernel with only the
> most important fixes (e.g. ptrace, ext3) and no new features.

You can do this on your own.  So what?

Releasing an official 2.4.21 with some fixes (and no new features) is
just a PR issue.  I've already seen people comparing the alleged IIS
bug (or this new IE hole) and the ptrace() bug...

Re: Release of 2.4.21

[Jeff Garzik]

On Thu, Mar 20, 2003 at 09:43:01PM +0100, Florian Weimer wrote:
> Releasing an official 2.4.21 with some fixes (and no new features) is
> just a PR issue.  I've already seen people comparing the alleged IIS
> bug (or this new IE hole) and the ptrace() bug...

Comparing, how?  There is no comparison.

The ptrace bug is only one of several local root holes.  IIS would imply
a remote vulnerability, something _far_ more serious.

This specific ptrace hole is closed, yay.  Now what about the other
10,001 that still exist?  People are blowing this ptrace bug WAY
out of proportion.   The only reason why it demands a modicum of
vendor responsibility is that a-holes are making easy-to-use exploits
available for the script kiddies.

In my more cynical moods, I wish bugtraq'ers would start posting
exploits to all the races in GNU coreutils (cp/mv/rm/...).  Assuming
such actions would (finally) lead to bug fixes.... maybe then I will
start taking local root holes a bit more seriously.  I will no more
than hint about this in public, but will respond privately with details
(if I know you).

	Jeff

Re: Release of 2.4.21

[H. Peter Anvin]

Followup to:  <20030320210305.GH8256@gtf.org>
By author:    Jeff Garzik <jgarzik@pobox.com>
In newsgroup: linux.dev.kernel
> 
> The ptrace bug is only one of several local root holes.  IIS would imply
> a remote vulnerability, something _far_ more serious.
> 

Don't forget: local root exploit + remote non-root exploit -> remote
root exploit.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: Release of 2.4.21

[Sebastian D.B. Krause]

On 3487 September 1993, Jeff Garzik wrote:
> The ptrace bug is only one of several local root holes.  IIS would imply
> a remote vulnerability, something _far_ more serious.
>
> This specific ptrace hole is closed, yay.  Now what about the other
> 10,001 that still exist?  People are blowing this ptrace bug WAY
> out of proportion.

That may be true, but inspite of that there is another important and
dangerous bug in 2.4.20 (the ext3 thing) that IMHO is enough reason
to release a new kernel.

Re: Release of 2.4.21

[Oliver Feiler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 March 2003 23:08, Sebastian D.B. Krause wrote:
>
> That may be true, but inspite of that there is another important and
> dangerous bug in 2.4.20 (the ext3 thing) that IMHO is enough reason
> to release a new kernel.

Btw, what ext3 patches are these exactly?

- From subdir 00-merged/ at 
http://people.redhat.com/sct/patches/ext3-2.4/dev-20030314/

More/other patches? There seem to be some (all?) of those mentioned in the 
.21-pre changelog but can someone please cleary state what ext3 patches 
should be applied?


- -- 
Oliver Feiler  <kiza@(kcore.de|lionking.org|gmx(pro).net)>
http://kiza.kcore.de/    <--    homepage
PGP-key      -->    /pgpkey.shtml
http://kiza.kcore.de/journal/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+evI+OpifZVYdT9IRAuksAJ45QBi9gPXrKRHrPGgDlRmanlSmNgCguKFL
v5PrWhB/49KKgeE/kvwxF1A=
=A3QG
-----END PGP SIGNATURE-----

Re: Release of 2.4.21

[Arador]

On Thu, 20 Mar 2003 16:03:05 -0500
Jeff Garzik <jgarzik@pobox.com> wrote:

> 10,001 that still exist?  People are blowing this ptrace bug WAY
> out of proportion.   The only reason why it demands a modicum of

Indeed, everybody i know is recompiling and rebooting; although
they're just plain linux where they're the one users and 
remote login isn't allowed.....

Re: Release of 2.4.21

[Chris Wright]

* Jeff Garzik (jgarzik@pobox.com) wrote:
> 
> The ptrace bug is only one of several local root holes.  IIS would imply
> a remote vulnerability, something _far_ more serious.
> 
> This specific ptrace hole is closed, yay.  Now what about the other
> 10,001 that still exist?  People are blowing this ptrace bug WAY
> out of proportion.   The only reason why it demands a modicum of
> vendor responsibility is that a-holes are making easy-to-use exploits
> available for the script kiddies.

I know it's already been said, but IMHO it needs to be underscored.  Local
root holes are just a simple non-root remote exploit away from being
remotely exploitable root holes.  Both are often considered
insignificant, and that is scary!  As far as fileutils...couldn't agree
more ;-)  But that doesn't make a locally exploitable root hole in the
kernel any less significant.

cheers,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

RE: Release of 2.4.21

[Dow, Benjamin]

What would concern me about releasing 2.4.21 with just this bugfix is the
reports I've seen of it breaking other things (kill, etc).  Have these
issues been addressed?

RE: Release of 2.4.21

[Alan Cox]

On Thu, 2003-03-20 at 21:17, Dow, Benjamin wrote:
> What would concern me about releasing 2.4.21 with just this bugfix is the
> reports I've seen of it breaking other things (kill, etc).  Have these
> issues been addressed?

No one has sent me any patches, any analysis of the changes identifying
problems or alternative fixes.

Alan

Re: Release of 2.4.21

[Florian Weimer]

Jeff Garzik <jgarzik@pobox.com> writes:

> On Thu, Mar 20, 2003 at 09:43:01PM +0100, Florian Weimer wrote:
>> Releasing an official 2.4.21 with some fixes (and no new features) is
>> just a PR issue.  I've already seen people comparing the alleged IIS
>> bug (or this new IE hole) and the ptrace() bug...
>
> Comparing, how?  There is no comparison.

You know it, I know it, our readers know it.  But the press puts them
on the same level nevertheless.

> This specific ptrace hole is closed, yay.  Now what about the other
> 10,001 that still exist?  People are blowing this ptrace bug WAY
> out of proportion.

I agree completely.  Local security on traditional UNIX-like systems
is *so* poor that this bug doesn't really matter.  No admin of a sane
mind lets untrusted users access important systems.

> The only reason why it demands a modicum of vendor responsibility is
> that a-holes are making easy-to-use exploits available for the
> script kiddies.

No, you miss a point.  These exploits are important to keep you kernel
developers honest.  Otherwise, you would have fixed this quitely, like
a couple of other bugs.  Admins would assume that kernels offered a
decent level of local security, which can lead to very questionable
decisions.