Security version case study

[Tim Gardner]

Andy,

The current Intrepid versions are:

release: 2.6.27-7.14
security: 2.6.27-7.16
updates: 2.6.27-7.16
proposed: 2.6.27-8.17

The pockets are listed in priority order, release being highest. Each
subsequent pocket should be a superset with regard to code commits,
though it sometimes takes awhile to converge on that solution.

For example, the current set of CVEs is going to cause an ABI bump in
the -security kernel. The next available, non-conflicting, ABI number is
-9, so the next -security upload will be 2.6.27-9.18.

All of the CVE commits in 2.6.27-9.18 are cherry-picked into the next
-proposed kernel, which will probably be 2.6.27-10.19. Eventually, that
kernel (or one of its decedents) will get promoted to -updates.

So, soon after uploading the security kernel, the pockets will look like
this:

release: 2.6.27-7.14
security: 2.6.27-9.18
updates: 2.6.27-7.16
proposed: 2.6.27-8.17

Eventually they should look like this:

release: 2.6.27-7.14
security: 2.6.27-9.18
updates: 2.6.27-10.19
proposed: 2.6.27-10.20 (maybe)

The only hard rule is that whatever kernel is promoted from -proposed to
-updates _must_ have all of the -security kernel CVE patches.

The version of kernel and packages that get updated depend entirely on
the pockets that are enabled in one's /etc/apt/sources.list. Each pocket
has a linux-meta package that references the kernel packages in that
pocket. As with all debian packages, the highest version of linux-meta
wins. Its worth noting that the kernel packages are not compared within
pockets if they have a different ABI number, since the ABI is part of
the package name as well as being part of the package version.

Does that make sense? I know its damn confusing, and I may have
mis-stated something.

rtg
-- 
Tim Gardner tim.gardner at canonical.com