Bug database labels are used very heavily for security bugs. We rely on the labels being correct for a variety of reasons, including driving fixing efforts, driving release management efforts (merges and release notes) and also historical queries and data mining.
Because of the extent to which we rely on labels, it is an important part of the Security Sheriff duty to ensure that all security bugs are correctly tagged and managed. But even if you are not the Sheriff, please fix any labeling errors you happen upon.
Any issue that relates to security should have one of the following:
Security_Severity-{Critical, High, Medium, Low, None}: Designates the severity of a vulnerability according to our severity guidelines.
Pri-#: Priority should generally match Severity:
Security_Impact-{Head, Beta, Stable, None}: Designates which branch(es) were impacted by the bug. Only apply the label corresponding with the earliest affected branch. None means that a security bug is in a disabled feature, or otherwise doesn't impact Chrome. Note that Security_Severity should still be set on Security_Impact-None issues, as if the feature were enabled or the code reachable.
Restrict-View-{SecurityTeam, SecurityNotify, Google, SecurityEmbargo}: Labels that restrict access to the bug. Meaning and usage guidelines are as follows:
If multiple restriction labels are appropriate, set all of them. Note that all restriction labels must be satisfied for a user to have access to a bug.
reward-{topanel, unpaid, na, inprocess, #}: Labels used in tracking bugs nominated for our Vulnerability Reward Program.
M-#: Target milestone for the fix.
Component: For bugs filed as Type-Bug-Security, we also want to track which component(s) the bug is in.
ReleaseBlock-Stable: When we find a security bug regression that has not yet shipped to stable, we use this label to try and prevent the security regression from ever affecting users of the Stable channel.
OS-{Chrome, Linux, Windows, ...}: Denotes which operating systems are affected.
Merge-{Request-?, Approved-?, Merged-?}: Security fixes are frequently merged to earlier release branches.
Release-#-M##: Denotes which exact patch a security fix made it into. This is more fine-grained than the M-# label. Release-0-M50 denotes the initial release of a M50 to Stable.
CVE-####-####: For security bugs that get assigned a CVE, we tag the appropriate bug(s) with the label for easy searching. Type-Bug-Security bugs should always have Security_Severity, Security_Impact, OS, Pri, M, Component, and an owner set.
It can be hard to know which OS(s) a bug applies to. Here are some guidelines:
foo_{win,linux,mac,...}.cc, it's specific to the named platform.foo.mm) is particular to macOS and iOS. (But note that most of our Objective-C++ is particular to macOS or iOS. You can usually tell by the pathname.)ui/message_center/views) is used on Windows, Linux, Chrome OS, and perhaps Fuchsia (?). Views for macOS is increasingly a thing, but Cocoa code (e.g. ui/message_center/cocoa) is particular to macOS.Security labels guide the actions taken by SheriffBot. The source of truth for the actual rule set is go/sheriffbot-source (sorry, Google employees only). The motivation behind these rules is to help automate the security bug life cycle so security sheriffs and security engineers in general spend less time updating bugs and can do more useful work instead.
The following sections describe the current set of rules relevant to security bugs. The list below only describes rules that change the labels described above. There are additional rules for sending nag messages and janitorial tasks; check the sheriffbot source for details.
Only bugs that affect stable should carry a release label, this rule removes release labels that are set on bugs not affecting stable.
There should be exactly one Security_Impact-X label and it should be one of the 4 valid impact labels (None, Stable, Beta, Head). This rule removes any invalid and excess impact labels.
Based on M-# milestone labels this rule assigns corresponding Security_Impact-X labels if they are incorrect or absent.
Bugs that are labelled with milestones earlier than the current milestone will be relabeled to set the label for the current milestone and Security_Impact-Stable.
Bugs that carry a Security_Impact-X label but are missing a milestone label will be assigned the M-# label corresponding to the respective milestone.
If there's a high or medium severity security regression in beta or ToT, add a ReleaseBlock-Stable label to prevent that regression to be shipped to users.
Similarly, critical security regressions are marked ReleaseBlock-Beta.
Adjust Pri-# according to the priority rules for severity labels described above.
Remove Restrict-View-SecurityTeam and Restrict-View-SecurityNotify from security bugs that have been closed (Fixed, Verified, Duplicate, WontFix, Invalid) more than 14 weeks ago and add the allpublic label to make the bugs accessible publicly. The idea here is that security bug fixes will generally require 12 weeks to ship (2 release cycles for ToT changes to hit stable). This catches cases where the bug owner forgets to mark the bug public after the fix is released.
Replace Restrict-View-SecurityTeam with Restrict-View-SecurityNotify for fixed security bugs. Rationale is that while fixed bugs are generally not intended to become public immediately, we'd like to give access to external parties depending on Chromium via security-notify@chromium.org.
Fixed security bugs that affect stable or beta and are critical or high severity will automatically trigger a merge request for the current beta branch.
No need to stop a release if the bug doesn't have any consequences.
Security bugs that have a merge label (but excluding bugs with component:OS) are marked as fixed automatically. The rationale is that if something gets merged to a release branch, there's a high likelihood that the bug is actually fixed.
Given the importance and volume of labels, an example might be useful.