Security version case study

[Andy Whitcroft]

On Tue, Nov 18, 2008 at 12:08:48PM -0700, Tim Gardner wrote:
> 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.

The only caveat here is:

If our master branch is far ahead of proposed, and we are not comfortable
releasing master to proposed soon then we might have to also branch off
the version in the proposed pocket and just add the cve's there as well
and re-release that also.

> 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.

I think that reads pretty conherently.  It is of course for the case
where the security update triggered an ABI bump.  It would be worth
also doing the same thought process for a non-ABI bump probabally.
Though the reasoning is the same just the answers differ.

-apw