Process for providing security updates for chromium-browser

Chris Coulson chris.coulson at canonical.com
Wed Aug 18 13:38:32 BST 2010


Hi,

I'm currently working on trying to get Chromium in to main for Maverick,
and part of that involves ensuring we have an efficient means to provide
security updates for users. My understanding of what happens currently
is (I'm not directly involved with supporting Chromium just yet):

1) Upstream provides a security update on the stable branch
2) We build this in the security PPA
3) This is pocket copied to *-proposed, where it sits for the usual 7
day maturing period
4) It gets copied to *-security

The issue with this process is that we are leaving users exposed to
publicly disclosed vulnerabilities for 7 days. In addition to this,
upstream are very keen on us being able to ship security updates in a
more timely fashion.

The process we use for updating Firefox and Thunderbird is different to
this, in that we skip *-proposed (ie, we build in the security PPA and
then copy the update to *-security after we've tested it). 

I would like permission to use a similar process for Chromium too.

Some background information on the release process and maintenance cycle
for Chromium (and how it differs to Mozilla) might be useful for you:

- Chromium has a stable, beta and development branch. 
- The branch we base our packaging from in the archive is stable. 
- The stable branch receives updates for security fixes at a frequency
of approximately every 10 - 14 days (this is based on the current upload
pattern for Chromium). 
- The time between fixing a security issue in stable and then releasing
it to the stable channel is typically less than 1 day (this is the
window in which we need to prepare and test the Ubuntu builds). 
- New "major" versions are released to the stable channel approximately
every 6 weeks. The purpose of these new major versions is to allow new
features to trickle in to stable from the beta channel without users
having to wait several months for a new version. 
- Once a new stable version is released, support for the previous one is
ended immediately.

This is different to Mozilla in the following ways:
1) Mozilla don't release security updates as soon as they've fixed them
in the current stable branch. Instead, they tend to release updates in
batches and less frequently. They initially push security updates to
their beta channel for testing before they officially release. This
gives us a much bigger window in which to prepare and test our Ubuntu
builds (typically 1 - 2 weeks)
2) The updates to the Chromium stable branch are purely for security
fixes, with features only appearing in new major versions (every 6
weeks). Mozilla tend to mix new features and other bug fixes in to their
regular security updates (eg, introducing out-of-process plugins in to
the 3.6.4 update, which was quite a major feature addition for a regular
security update)
3) Mozilla continue to support previous stable releases for some time
after releasing a new major version (although this overlap is getting
significantly shorter now). No more than 1 stable version of Chromium is
supported at any one time.
4) Mozilla release new major versions much less frequently. However,
their major versions generally introduce more significant changes than
what we expect with the 6-weekly cycle for Chromium, as Mozilla are
already allowing smaller features to trickle in to the regular security
updates.

The obvious risk to this is that we currently enjoy quite a large window
in which we can test Mozilla security updates to ensure that they are
regression free. This window is virtually non-existant for Chromium once
we factor in the amount of time it takes to actually build it, so we
will be mostly at the mercy of upstream QA for security updates.


Regards
Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/technical-board/attachments/20100818/dd7caacc/attachment.pgp 


More information about the technical-board mailing list