Update release/docs sections to use the new patch release terminology
Patch releases have been repurposed to include patch and security fixes deprecating the term 'security release'. #20184 (closed) updated the patch and security namespaces, however there are still a good number of pages that still use the old term:
Click to expand
11:25:13 ❯ grep -nr 'security release' .
./metrics/release_manager_workload.md:82:https://docs.google.com/spreadsheets/d/1xENgrQwAQkA3ImtxsnqgQYEGxxevbUeNhXLFRUUKayk/edit#gid=1709173347 tracks the amount of work involved with preparing a security release.
./metrics/release_manager_workload.md:90: 4. Number of manual steps (on the process): The completed checkbox count shown on the security release preperation issue. This number will be used to track the manual complexity of the process
./metrics/release_manager_workload.md:92: 6. Critical security release process used? Yes or No. Used to track the difference in effort between the two processes
./metrics/release_manager_workload.md:93: 7. Wall time of process (hours per release): Number of working hours between the process start time and the release completion time. Both times are taken from the Security release issue activity log to track the overall number of hours needed to prepare a security release
./metrics/release_manager_workload.md:98: 3. Number of non-security fixes released: Number taken from the release blog post. This number might help to track additional complexity coming from including non-security fixes in a security release
./metrics/release_manager_workload.md:104: 3. Active time spent on Merging backport phase of release (hours): The time taken to complete all tasks in the One Day before Due section of the security release preparation issue. The number is tracked using the Activity log on the Security release issue
./metrics/release_manager_workload.md:105: 4. Active time spent on release tagging (hours): Calculated using a combination of Slack for the start time and the Activity Log time on the security release issue as the end time
./metrics/release_manager_workload.md:106: 5. Active time spent on release publishing (hours): Calculated using a combination of Slack for the start time for publishing and the Activity Log time on the security release issue as the end time (currently the time the last version is created)
./metrics/release_manager_workload.md:107: 6. Active time spent on post-publishing steps phase of release (hours): The time taken to complete all tasks in the Final Steps section of the security preparation issue. Tracked using the Activity Log on the security release issue
./general/security/bugs_introduced_by_security_merge_request.md:8:and the timeline of the security release.
./general/security/bugs_introduced_by_security_merge_request.md:12:## Option 1 (Ideal): The bug introduced is fixed in the same security release
./general/security/bugs_introduced_by_security_merge_request.md:14:This is the ideal option, but it depends on the proximity of the security release due date. If the due date is in less
./general/security/bugs_introduced_by_security_merge_request.md:18:it is deployed to GitLab.com at least 48hrs before the security release due date. This option guarantees the security
./general/security/bugs_introduced_by_security_merge_request.md:19:issue and the bug fix are included in the security release.
./general/security/bugs_introduced_by_security_merge_request.md:21:Note the security release due date can't be delayed for compliance reasons and to avoid impacting the monthly release
./general/security/bugs_introduced_by_security_merge_request.md:29:with the security release, guaranteeing the vulnerability is fixed on GitLab.com and on self-managed installations.
./general/security/bugs_introduced_by_security_merge_request.md:32:Once the security release is out:
./general/security/bugs_introduced_by_security_merge_request.md:42:The security merge request is reverted and the security issue is removed from the security release. This implies the
./general/security/bugs_introduced_by_security_merge_request.md:44:vulnerability will be leaked once the security release is out.
./general/security/how_to_handle_gitaly_security_merge_requests.md:23:After the security release is published, re-enable the Gitaly update task.
./general/security/utilities/feature_flags.md:7:1. Continue with the security release change without the feature flag. Doing so
./general/security/utilities/feature_flags.md:24: release with the vulnerability exposed and follow up with a critical security release.
./general/security/utilities/merge_train.md:6:Every project that can be part of a security release has a security mirror (usually under
./general/security/utilities/merge_train.md:11:During a security release, security fixes are merged into the security mirror to keep security vulnerability
./general/security/utilities/merge_train.md:12:information private until the security release is published. Once security merge requests have been merged,
./general/security/utilities/merge_train.md:15:With mirroring broken during a security release, and since we deploy from the security mirror,
./general/security/security-engineer.md:41:The following guidance can be used while also refering to the documentation included in the [security release tools](https://gitlab.com/gitlab-com/gl-security/appsec/tooling/security-release-tools). Use the tooling to create the checklist task issue, which is the single source of truth for patch releases.
./general/security/security-engineer.md:80:For all steps in the process, keep in mind that there might be a [GitLab Runner security release](https://gitlab.com/gitlab-org/gitlab-runner/-/issues?label_name[]=upcoming%20security%20release) going on at the same time and that it should be included in the process (blog post, CVE ID requests, notifications on H1 reports, etc.)
./general/security/security-engineer.md:194:1. Create a security tracking issue with ~security and ~"upcoming security release" labels (e.g https://gitlab.com/gitlab-org/gitlab/-/issues/297419).
./general/security/far_reaching_impact_fixes_or_breaking_change_fixes.md:8:[controlled roll out](https://about.gitlab.com/handbook/engineering/development/processes/rollout-plans/). For high and critical severity security issues, [we must always follow the security release process](https://docs.gitlab.com/ee/policy/maintenance.html#security-releases).
./general/security/how_to_sync_security_with_canonical.md:3:This How-to explains the different Security to Canonical syncing tasks involved with security releases and gives steps on how to achieve them.
./general/security/how_to_sync_security_with_canonical.md:5:There are two points in security releases where conflicts can occur:
./general/security/how_to_sync_security_with_canonical.md:6:1. During the early merge stage of security release preparation. These conflicts are caused by conflicting changes being merged into the Canonical master branch and causing the merge-train to fail. [More details on how to resolve](general/security/how_to_sync_security_with_canonical.md#dealing-with-merge-conflicts-caused-by-conflicting-changes-being-merged-into-canonical).
./general/security/how_to_sync_security_with_canonical.md:7:2. At the end of the security release when we re-sync the security and canonical repos. [More details on how to do this](general/security/how_to_sync_security_with_canonical.md#re-syncing-the-security-and-canonical-repos-at-the-end-of-the-security-release).
./general/security/how_to_sync_security_with_canonical.md:13:Auto-deploy branches are created from the Security master branch to allow deployments to continue during security release preperation. This means that in normal operations a change is merged to Canonical master, mirrored to Security master and then incuded in a future auto-deploy branc to be deployed.
./general/security/how_to_sync_security_with_canonical.md:15:This changes during security release preperation.
./general/security/how_to_sync_security_with_canonical.md:17:To allow security fixes to be applied to GitLab.com and included in security releases without the vulnerability being revealed, we merge the security fixes directly into the Security master branch. At the same time, regular changes are being merged into the Canonical master branch. This causes Canonical and Security repositories to diverge.
./general/security/how_to_sync_security_with_canonical.md:22:At the end of the security release we re-sync the Security and Canonical repositories to resolve the divergance and re-enable mirroring.
./general/security/how_to_sync_security_with_canonical.md:26:During the 'early-merge' phase of a security release, security fixes are being merged to the Security master branch at the same time as regular changes are being merged to the Canonical master branch. The merge train handles the divergance to bring the Canonical changes into the Security master to allow changes to be included in upcoming deployments.
./general/security/how_to_sync_security_with_canonical.md:131:## Re-syncing the Security and Canonical repos at the end of the security release
./general/security/how_to_sync_security_with_canonical.md:133:Once the security release has been published we can re-sync the Security and Canonical repos. This will bring all Security fixes into the Canonical master branch to resolve the divergance.
./general/security/how_to_sync_security_with_canonical.md:143:[Details about how to so this can be seen in the security release issue template](https://gitlab.com/gitlab-org/release-tools/-/blob/a986ce2668ea0b4bd31acf859587a7bb4352b13a/templates/security_patch.md.erb#L196-203)
./general/security/how_to_sync_security_with_canonical.md:147:Due to compliance requirements, release managers should use the tools described in the above sections to re-sync at the end of the security release.
./general/deploy/auto-deploy.md:361:Security patches included in the regular monthly security release will be deployed to GitLab.com prior to publishing by merging the changes into the default branch, and manually including them in the active auto-deploy branch.
./general/deploy/release_metadata.md:14:- `14.7.7` security release: [releases/14/14.7.7.json](https://ops.gitlab.net/gitlab-org/release/metadata/-/blob/master/releases/14/14.7.7.json).
./general/pro-tips.md:99:ChatOps commands. The only exception to this is security releases, which should
./general/picking-into-merge-requests.md:13:security release on those branches. Beyond that the trade-offs are complexity,
./general/patch/release_managers.md:216:[security release deadlines]: https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/process.md#security-release-deadlines
./general/overview-of-the-auto-deploy-pipelines.md:27:The branches are created on security repositories to account for security releases.
./runbooks/updating-releases.md:14:- `appsec`: (Optional) A list of AppSec engineers to act as a security release managers for the given version.
./runbooks/security/revert-security-merge-request.md:21:1. Figure out the [security release manager] for the released monthly release. (It's usually the row _below_ the
./runbooks/security/revert-security-merge-request.md:25:implications of the revert merge request being published as part of the upcoming the security release.
./runbooks/security/revert-security-merge-request.md:28:that the revert will be published with the upcoming security release.
./runbooks/security/revert-security-merge-request.md:33:[security release manager]: https://about.gitlab.com/community/release-managers/
./runbooks/security/security_fixes_introducing_breaking_changes.md:16: * The security release manager or a security manager from AppSec.
./runbooks/security/security_fixes_introducing_breaking_changes.md:29:5. Then, [organize the security release]: After the incident has been mitigated, timeline of
./runbooks/security/security_fixes_introducing_breaking_changes.md:30: a security release should be re-evaluated to consider the re-introduction of the security fix.
./runbooks/security/security_fixes_introducing_breaking_changes.md:65:## Organize the security release
./runbooks/security/security_fixes_introducing_breaking_changes.md:69:publish the security release. There are two options
./runbooks/security/security_fixes_introducing_breaking_changes.md:71:1. Remove the security fix from the security release. AppSec approval is required for
./runbooks/security/security_fixes_introducing_breaking_changes.md:74:1. [Delay the security release]. If the security fix can't be dropped from the security
./runbooks/security/security_fixes_introducing_breaking_changes.md:75: release, the security release due date needs to be postponed to account for the
./runbooks/security/security_fixes_introducing_breaking_changes.md:78:Additionally, Release Managers should consider "blocking" the security release by
./runbooks/security/security_fixes_introducing_breaking_changes.md:80:could lead to other incidents and delay the security release even further. One way to block a
./runbooks/security/security_fixes_introducing_breaking_changes.md:81:security release is to actively keep an eye on the Tracking Security Issue and ensure no
./runbooks/security/security_fixes_introducing_breaking_changes.md:92:of the security release is viable.
./runbooks/security/security_fixes_introducing_breaking_changes.md:94:#### Delay the security release
./runbooks/security/security_fixes_introducing_breaking_changes.md:96:Delaying a security release is a decision that belongs to AppSec in coordination with
./runbooks/security/security_fixes_introducing_breaking_changes.md:102: security release.
./runbooks/security/security_fixes_introducing_breaking_changes.md:104: associated with the security release, e.g. there could be S1/S2 security fixes waiting
./runbooks/security/security_fixes_introducing_breaking_changes.md:108:* No gitaly updates - If Gitaly security fixes are associated with the security release, the
./runbooks/security/security_fixes_introducing_breaking_changes.md:109: Gitaly updates are paused until the security release is out.
./runbooks/security/security_fixes_introducing_breaking_changes.md:118: the security release.
./runbooks/security/security_fixes_introducing_breaking_changes.md:125:[Organize the security release]: #organize-the-security-release
./runbooks/security/git-security-patches.md:94:### Critical security release
./runbooks/security/git-security-patches.md:96:If the Git vulnerability being patched is an S1, [open a critical security release issue](../release-manager.md#Critical-Security-Releases)
./runbooks/security/git-security-patches.md:103:Adjust the dates in the critical security release to account for this.
./runbooks/security/git-security-patches.md:107:Add the following steps to the critical security release. If the heading already exists in the critical security release
./runbooks/security/git-security-patches.md:157:- [ ] Before tagging the security release, add the following variable to
./runbooks/security/git-security-patches.md:161: should include the Git fixes. For example if the security release is for 15.7.2, 15.6.4, 15.5.7, the value of the
./runbooks/security/how-to-grant-permissions-for-repo-sync-push.md:3:This guide shows the steps an EM needs to go through to grant push permissions if needed to complete the security release sync.
./runbooks/security/how-to-grant-permissions-for-repo-sync-push.md:9:One of the final steps for completing a security release involves syncing all changes back into the canonical repo. We have tools to do this in a compliant way but these can fail, for example if there is a lot of other activity taking place on the Canonical default branch. As a final resort, Delivery Engineering Managers we can grant direct push permissions to allow a release manager to push the changes directly to the default branch to complete the release.
./runbooks/security/upstream_security_patches.md:21:1. Monkey patch the vulnerability on GitLab in a security release following the security release process with backports as we would for any other fix
./runbooks/security/upstream_security_patches.md:22: - For ~"severity::1" issues it should be a critical security release
./runbooks/security/upstream_security_patches.md:25: - This issue should remain confidential until both the security release and the fixed version of the third-party dependency are out
./runbooks/security/upstream_security_patches.md:33:1. Backport the update in the security release
./runbooks/security/upstream_security_patches.md:45:1. Monkey patch the vulnerability on GitLab in a security release following the [security release process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md#process) with backports as we would for any other fix
./runbooks/security/upstream_security_patches.md:46: - For ~"severity::1" issues it should be a critical security release
./runbooks/security/upstream_security_patches.md:54:1. Backport the update in the security release
./runbooks/how_to_speed_up_auto_deploy_process_for_urgent_merge_requests.md:3:Specific situations such as mitigating incidents or unblocking the security release,
./runbooks/how_to_speed_up_auto_deploy_process_for_urgent_merge_requests.md:22:This process should be used for critical security releases:
./runbooks/fix-branch-divergence.md:64: processes of a security release which is where we grab our commits from and
./README.md:48:- [Release manager in security release](general/security/release-manager.md)
./README.md:49:- [Security engineer in security release](general/security/security-engineer.md)
./README.md:50:- [Developer in security release](general/security/developer.md)
./README.md:51:- [Quality engineer in security release](general/security/quality.md)
./components/managed-versioning/security_release.md:3:The security release process for components in managed versioning
./components/managed-versioning/security_release.md:4:takes place under the general [security release
./components/managed-versioning/security_release.md:24:1. Ping release-managers (`@gitlab-org/release/managers`) on the security release
./components/managed-versioning/security_release.md:69:`gitlab-org/gitlab` before the security release completes, this merge
./components/managed-versioning/security_release.md:89:security release.
./components/managed-versioning/security_release.md:91:To add the merge request to the security release:
./components/managed-versioning/security_release.md:128:a given security release. In order to correctly deploy multiple fixes
./components/managed-versioning/security_release.md:129:for the same component in a single security release, an accumulation
./components/managed-versioning/security_release.md:139:the component until the security release completes (usually 4-5 days).
./components/managed-versioning/security_release.md:149:security release, we cannot prioritize component deployments unless it
./components/managed-versioning/security_release.md:150:fixes a problem with the security release.
./components/managed-versioning/security_release.md:152:The security release date varies, so if you want to understand when
./components/managed-versioning/security_release.md:154:[upcoming security release tracking
./components/managed-versioning/index.md:32:regular releases during a security release.
./components/managed-versioning/index.md:41:- Simplified security release process
./components/managed-versioning/index.md:91:### security releases
./components/managed-versioning/index.md:93:The security release process for components under managed versioning
./components/managed-versioning/index.md:94:takes place under the general [security release
./release_manager/release-manager-incident-guide.md:24: id3_3{Does AppSec want a critical security release?}
./release_manager/release-manager-incident-guide.md:27: id3_4(Coordinate with AppSec to <br/>start a critical security release)
./release_manager/release-manager-incident-guide.md:43: id10(Ask the MR author to follow the <br/>security developer workflow to include the MR in the next security release)
./release_manager/release-manager-incident-guide.md:53:2. Do not merge a security MR into security master before the start of a security release.
./release_manager/release-manager-incident-guide.md:55:when the security release starts.
./release_manager/index.md:4:[patch releases] and [security releases] for that version.
./release_manager/index.md:77:### Monthly, patch and security releases commands
./release_manager/index.md:89:| `/chatops run release prepare --security` | Creates a release task issue for the upcoming security release |
./release_manager/index.md:94:| `/chatops run release tag --security 15.x.x` | Tags 15.3.3 as a security release |
./release_manager/index.md:95:| `/chatops run publish --security` | Publishes the security release |
./release_manager/index.md:219:Exception is reserved for [critical security releases](../general/security/process.md#critical-security-releases), which should be
./release_manager/index.md:306:[security releases]: ../general/security/process.md
The purpose of this issue is to update such pages to use the new terminology