the Chromium logo

The Chromium Projects

Security Release Management

Merging Fixes

Engineers outside the Chrome Security team shouldn’t request merges for security fixes. Instead, please mark the bug as Fixed and we’ll take care of it. The instructions below are for the Chrome Security team itself.

TODO(chrome-security@): Identifying fixes to merge.

Security fixes often need to be merged to the Stable or Beta branch. One of the key considerations in picking a fix to merge is assessing the risk of breakage, which the bug’s owner should be able to convey. For risky fixes you should consider bumping it to a later milestone. Generally, you should consider merging the following:

For Critical (S0) and High (S1) severity bugs, we aim to fix users fast and work directly with Chrome TPMs to make sure any merge or release is done safely. The following are general recommendations on when / where to merge:

Other factors to consider in your merge vs. no-merge calculation are:

Your worklist for merges is defined by the following bug database criteria:

(Note: beware of querying on the milestone. At this stage in the bug's life, the milestone label represents the earliest affected release at the time the bug was filed. So if current stable is M122, there might still be bugs in this list which are M121, M120, etc., if we've been a little slow in fixing them. Conversely, anything marked M122 denotes a regression since M121 stable, so it only needs to be merged to the M122 beta.)

TODO(bug owner): Merging a security patch.

When a security merge has been approved, please go ahead and merge.

To avoid accidentally losing a fix for a Chrome release, branch merges should be done in a "newer first" manner. For example, if you're merging a fix to M121 stable and M122 is branched and affected, then merge to M122 first. Such a strategy can also be used to bake a fix on the M122 branch in order to gain confidence about an M121 stable channel merge.

How to merge

You should merge fixes with gerrit, which automates most of the process. If the gerrit merge does not apply cleanly you may want to reconsider whether the fix will introduce an unacceptable breakage risk. In the event that you can’t use gerrit to merge a fix, you still have the option of manually merging from a branch checkout. This follows the normal developer normal patch process.

Post-merge bug cleanup.

Once the fix is successfully merged you will need to:

  1. Update the bug with the merge revision numbers (one for each branch you've merged to).
  2. Set the merge status to Merge-Approved to Merge-Merged (if drover didn't do so).

Release Notes

For every new release, we include notes from security bugs that match the following search criteria:

For example, this link shows the security fixes that went into the initial Beta -> Stable promotion of Chrome 122, and this link shows the security fixes that went into the first post-stable patch of the Chrome 122 branch.

Every externally reported issue gets assigned a CVE ID per MITRE's CVE Counting Rules. Chrome's CVE pool is here (Google internal-only link, sorry). As of Chrome 27, we're focusing the release notes on externally reported issues. This mirrors how Mozilla Firefox arranges their release notes, saves the precious resource of CVEs, saves a lot of time in preparing release notes, and appropriately focuses our security release notes on the excellent contributions and rewards of external researchers.

CVEs are allocated when the stable release that contains the fix is released, and they are then placed into the bug tracker using the CVE label, and copied into the release notes. An example of how it looks is here for the Chrome 121 release notes.

There is no longer any need to pre-notify with a copy of release notes. Very few list members were finding it useful or actionable.