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

Re: Security Supporting Debian Kernels in Sarge



Martin Schulze wrote:

> Nathanael Nerode wrote:
>> >   2. It is insane to expect us to support three main kernel lines
>> >      (2.2, 2.4 *and* 2.6).
>> The main problem here appears to be the arch which still isn't supported
>> by
>> 2.4 or 2.6, namely m68k.  2.2 is pretty dead development-wise anyway and
>> is
> 
> You forgot the hypersparc sub-architectur of sparc, that also
> requires us to run a 2.2 kernel.
Oh, dear *&$%*, yes.  I guess security support for that would have to be
dropped too.

>> likely to security holes which were fixed incidentally during 2.4
>> development.  :-P
> 
> Yes.
> 
>> I see only one way to deal with that: drop security support for m68k. 
>> :-P
> 
> ... and sparc.
Well, only the one subarch.

> Even though, there is a smiley at the end of the line I don't see a need
> to continue arch-bashing again.

That was a "ew, that's a disgusting depressing possibility" smiley.  But I
just can't think of another way to avoid supporting three major kernel
lines.

2.6 is not standard for the Debian install yet (as well as being unsupported
for even more architectures than 2.4), so 2.4 has to be supported.  And not
supporting the newest version would be perverse and would cause trouble for
even more people than not supporting 2.2.

I don't see any way to hurry up any of the subarches' support for 2.4/2.6,
so....

One point is that the remaining subarches using 2.2 are probably less likely
to be security-conscious systems than systems than those using 2.4 and 2.6,
so dropping security support for them might not bite *too* hard.

>> Bleah!  Who isn't using 2.4.25?  Fess up!  If there are known
>> problems with 2.4.25 on your subarch or variant, fix them!
> 
>>From some architectures, I know that this is being worked on, partially
> inspired by the problems we've had with security updates.  Unfortunately,
> it's not as easy as we would like it to be.
> 
>> > kernel-source-2.6.3   testing   2.6.3-2     all source
>> > kernel-source-2.6.4   testing   2.6.4-1     all source
>> > kernel-source-2.6.5   testing   2.6.5-1     all source
>> I really don't see why we need all of these.  Can't we just stick with
>> they
>> newest 2.6 and leave out the previous point releases?  2.6 point releases
>> seem to have been pretty good about not breaking anything.  Why not, for
>> that matter, just have a kernel-source-2.6 package?
> 
> Are you able to monitor which 2.6 kernels enter unstable/testing and
> discuss with the port maintainers that use them whether older versions
> could be dropped?  That would hopefully improve this part of the problem.
I try sometimes.  It's a many-person job, unfortunately.

>> > There are also 31 kernel-image packages for various architectures and
>> > versions.  This is too much!
>> > 
>> > kernel-image-2.2.10-powerpc-apus  testing   2.2.10-13   source
>> This should be removed entirely; it's replaced by something newer.
> 
> It's removal should already have been requested...
> 
>> > kernel-image-sparc-2.2            testing   9           source
>> Which sparc subarch really needs this?
> 
> hypersparc.
Eeeewwww!

-- 
There are none so blind as those who will not see.



Reply to: