Security version case study

[Andy Whitcroft]

On Wed, Nov 19, 2008 at 12:06:28PM +0100, Stefan Bader wrote:
> 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?

Yes that is completely true, you could simply branch proposed and merge
the same branch into there.

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

-apw