FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 11-18-2008, 06:08 PM
Tim Gardner
 
Default Security version case study

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@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-19-2008, 09:40 AM
Andy Whitcroft
 
Default Security version case study

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-19-2008, 10:06 AM
Stefan Bader
 
Default Security version case study

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!



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-19-2008, 10:34 AM
Andy Whitcroft
 
Default Security version case study

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-19-2008, 01:55 PM
Tim Gardner
 
Default Security version case study

Stefan Bader wrote:

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

Good point. I'd forgotten that the new security kernel must also be
pocket copied to -updates since, by definition, it contains no other
changes then the CVE patches. That only holds true as long as we adhere
to the policy that all -security kernels are a strict superset of the
-updates kernel.

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-19-2008, 05:11 PM
Kees Cook
 
Default Security version case study

On Wed, Nov 19, 2008 at 07:55:08AM -0700, Tim Gardner wrote:
> Good point. I'd forgotten that the new security kernel must also be
> pocket copied to -updates since, by definition, it contains no other
> changes then the CVE patches. That only holds true as long as we adhere
> to the policy that all -security kernels are a strict superset of the
> -updates kernel.

I suspect this will hold true for a long time. Maintaining a "real" branch
between -security and -updates would be an even greater head-ache.

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 07:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org