Re: Security Supporting Debian Kernels in Sarge
Herbert Xu wrote:
> Martin Schulze <joey@infodrom.org> wrote:
>> We need to improve our kernel maintenance or it will be impossible to
>> support the Linux kernel security-wise in the future. We = Security
>> Team at the moment.
>
> I agree with what Martin has posted here.
>
> I'd like to propose a small addition on my part. When the current
> kernel-source/kernel-image source package split was first done, the
> kernel-image source packages were separated for each architecture as
> they all had separate release schedules. The separation in packaging
> gave them the independence which was appropriate at the time.
>
> Today, this is no longer the case for a number of architectures. The
> upstream kernel supports certain architectures well enough for it to
> be realistic for us to build certain architectures from one source
> package.
>
> In particular, the one non-i386 architecture that I maintain, alpha,
> has been supported well-enough that I see no problems in building it
> from the same source package that builds the i386 kernels, without
> fearing that this will delay the release of i386 kernel images in
> any way. You can see this from the changelog entries of the i386
> and alpha kernel image packages.
>
> Therefore I'd like to merge the two source packages as of the next
> upstream release. That is, both alpha and i386 kernel images will
> be built from the one source package.
>
> In itself this won't relieve the Security Team of much burden.
> However, what I'd like to see is the establishment of a set of
> architectures which we can call the "first class" architectures.
> They are the ones that are kept up-to-date enough upstream for
> synchronised releases with i386 to be possible without causing
> unacceptable delay on the i386 kernel images.
>
> Such architectures can then be built from one single source package.
> By my reckoning we might be able to do this for four architectures.
Cool! Which are the other two?
> That would be a significant decrease in the work load for the
> Security Team.
>
> Furthermore, we could then group the other architectures into a
> "second class" source package. This would mean that they will
> be slowed down to the release schedule of the slowest architecture.
> If (that's a pretty big if) this were acceptable to all the
> maintainers, then it would reduce the number of kernel-image source
> packages (and the number of kernel-source packages that we have to
> support) to exactly two.
Hmm. That would rock. :-)
There might be a slight elaboration on this which might be easier to get
port 'buy-in' for:
* The 'slowest architecture' for a given kernel line will not include the
architectures/subarchitectures for which that kernel line is still highly
experimental.
This would mean that 2.4 and 2.6 "second class" kernels would not be slowed
down by mac-m68k or hypersparc (until/unless they really become ready).
mac-m68k and hypersparc support in those kernels would just be in whatever
shape it was in, period. Similarly, 2.6 "second class" kernels probably
wouldn't pay attention to the timelines of certain architectures (I'm not
sure which).
--
There are none so blind as those who will not see.
Reply to: