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

Re: Linux 2.0.36 in slink?

On Wed, Dec 16, 1998 at 11:29:49AM -0800, Joey Hess wrote:
> Oscar Levi wrote:
> > My software development experience says we should stop making changes
> > except for release critical 'bugs'.  We need to be done with slink.
> A kernel with security holes _is_ a release critical bug.

Not necessarily true.  A crash bug that affects 1 out of 10000 runs of
a program is not release critical.  A security hole, in of itself, is
not a release critical bug.  I ship shrink-wrapped software for a
living--part of a living.  All software has bugs.  I ship on using
concrete criteria and I ship software with known bugs when the cost of
fixing it is greater than the value.

We don't have guidelines for release that we can use to decide if this
is important or not.  In your opinion, is it worth a three-week delay
to switch kernels?  I am not saying it would take that long.  I am
saying that a change like the kernel deserves extensive testing which
we are not now doing.  I'd rather ship a kernel with alleged security
holes than a broken distribution.

If someone installs a Debian system and they want to upgrade the
kernel then they are welcome to do so.  Shipping the new kernel
without thinking it through means that we could make it unusable for
everyone.  Whereas, the current setup does...kinda...work...sortof.

Please don't misunderstand me, though.  I think it may be a good idea
to ship 2.0.36.  

> > It makes more sense to ship an alternative kernel package for those
> > who are concerned with security.
> Who isn't?

I admin machines for a living--part of a living.  Believe it or not,
most folks are unconcerned about security.  How do we know?  They run
Windows NT servers and attach them to the Internet.  But seriously
folks, it isn't really a concern for most of them since they've never
experienced intrusion.


Reply to: