Security version case study

[Stefan Bader]

Andy Whitcroft wrote:
> 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.
> 

That was my reading of Tim's description. For the case of using master as the 
new proposed, my understanding would be to have the CVE's  by merging back the 
security branch. Wouldn't git not be powerful enough to branch from the last 
porposed release and merge security there as well?

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

Just to make it simpler for me, the step in between when respinning the current 
proposed...

release: 2.6.27-7.14
security: 2.6.27-9.18
updates: 2.6.27-9.18
proposed: 2.6.27-10.19

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

Giess that would look like

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

moving to

release: 2.6.27-7.14
security: 2.6.27-7.18
updates: 2.6.27-7.18
proposed: 2.6.27-8.19

and finally

release: 2.6.27-7.14
security: 2.6.27-7.18
updates: 2.6.27-8.19
proposed: 2.6.27-8.20 (maybe)

-- 

When all other means of communication fail, try words!