Security Updates and kernel-tree fun

[Horms <horms@debian.org>]

Hi,

Referring to
http://people.debian.org/~dannf/kernel-stats/kernel-avail.html
(thanks dannf) I notice that the following kernel-tree versions
are in use in Sarge: 

2.4.27-10: alpha, i386, ia64, powerpc  (latest)
2.4.27-9:  powerpc
2.4.27-8:  s390
2.4.27-5:  apus    (so old its scary)

2.6.8-16:  alpha, i386, ia64, m68k  (latest)
2.6.8-15:  sparc
2.6.8-13:  hppa, powerpc, s390


Now as I understand, security updates can only include security fixes.
Examining 2.6.8, in the case of arches that use 2.6.8-16, this
is easy enough, just add security fixes, make that 2.6.8-16sarge1,
and be done with it. Same for sarge2 and so on and so forth.

But what about the architectures that use 2.6.8-15 and 2.6.8-13?
The easy way out would be for them to use 2.6.8-16sarge1 as well.
But this means that they get a bunch of non-security patches
(though the majority are security fixes) to bring the up
to 2.6.8-16 and then the 2.6.8-16sarge1 fixes on top of that.
Presumably this is not acceptable to the security team
(though it would be great if it was).

So my idea is to extend the way we handle patches internally.  And as of
2.6.8-13 and 2.4.27-8 (2.4.27-5 is so old I really am scared), and mark
off all the security patches.  Fortunately this is mostly done in the
change log. And then allow us to build a kernel-source-2.6.8-16sarge1,
that can satisfy kernel-tree-2.6.8-Nsarge1, where 13 <= N <= 16.

Confused?

Let me try and illustrate by example.

Lets say we examine 2.6.8-13, 14, 15, 16 and what is currently in SVN.
We can do this by examining the series files - which are in turn
used to patch the tree to any known version.


series/2.6.8-14:     A.patch
                     b.patch
series/2.6.8-15:     C.patch
                     d.patch
series/2.6.8-16:     E.patch
                     f.patch
series/2.6.8-16.svn: G.patch
                     h.patch
(2.6.8-16.svn is just a dummy name I made up to represent
 the patches added to svn since 2.6.8-16)

So basically, if you have 2.6.8-13 and you want to get to 2.6.8-14,
you apply the patches A and b. And if you have 2.6.8-13 and you want to
patch all the way up to the latest and greatest, you 
add patches A, b, C, d, E, f, G and h. So far so good.

Now lets say, that through examination of the change log
we know that the uppercase patches (A, C, E, G) are either
security fixes, or required for a security fixes.

My idea is to copy the series directory and remove all the non-security
patches, using the data above this would give.

sec-series/2.6.8-14:     A.patch
sec-series/2.6.8-15:     C.patch
sec-series/2.6.8-16:     E.patch
sec-series/2.6.8-16.svn: G.patch

And then extend the way the patching works so that if I ask for
series/2.6.8-13sarge1, then it will patch up to 2.6.8-13
using the data in series (information for <= 2.6.8-13 not shown above),
and then use the data in sec-series beyond that.

So 2.6.8-13sarge1 would be a tree with the following applied:
  A.patch
  C.patch
  E.patch
  G.patch

2.6.8-15sarge1 would be
  A.patch
  b.patch
  C.patch
  d.patch
  E.patch
  G.patch

And 2.6.8-16sarge1 would be 
  A.patch
  b.patch
  C.patch
  d.patch
  E.patch
  f.patch
  G.patch


The nice thing about this approach is that the kernel-source package
would contain all the updated patches, so if people wanted
to build their own kernel, they could choose a fairly wide
range of patch levels. And the other nice thing is that most
of the security patches are already noted as such in the change logs,
so this wouldn't be terribly difficult to implement.

The bad thing about this is that its kind of complex,
and thus certain to confuse people. But I think that
is a reflection of the complexity of the problem at hand
(and indeed the complexity of the kernel packaging in Sarge).


-- 
Horms