Merge branch 'update-security-issue-and-mr-template-docs' into 'master'

Updates Security Release template

See merge request gitlab-org/gitaly!2311

2 files changed, 102 insertions, 90 deletions

diff --git a/.gitlab/issue_templates/Security Release.md b/.gitlab/issue_templates/Security Release.md
index f44aca06d..4cf25b0e2 100644
--- a/.gitlab/issue_templates/Security Release.md
+++ b/.gitlab/issue_templates/Security Release.md
@@ -1,94 +1,69 @@
-/title [Security Release] Release process for Gitaly issue #<issue-number>
-
-## What
-
-Release Gitaly security fixes into stable and master branches for Gitaly and
-GitLab at the correct times.
-
-## Owners
-
-- Team: `@gl-gitaly`
-- Most appropriate slack channel to reach out to: `#g_create_gitaly`
-- Best individuals to reach out to (note: may be the same person for both roles):
-  - **Contributor** (developing fixes): `{replace with gitlab @ handle}`
-  - **Maintainer** (releasing fixes): `{replace with gitlab @ handle}`
-
-## Version Matrix
-
-| GitLab Branch | Gitaly Branch  | Gitaly MR          |
-|---------------|----------------|--------------------|
-| `master`      | **TBD**        | <MR link>          |
-| `12.X`        | `12-X-stable`  | <backport MR link> |
-| `12.Y`        | `12-Y-stable`  | <backport MR link> |
-| `12.Z`        | `12-Z-stable`  | <backport MR link> |
-
-## Process
-
-### DO NOT PUSH TO GITLAB.COM!
-
-**IMPORTANT:** All steps below involved with a security release should be done
-in a dedicated local repository cloned from https://gitlab.org/gitlab/security/gitaly
-unless otherwise specified. Using a dedicated repository prevents leaking
-security patches by restricting the pushes to `gitlab.org/security` hosted origins.
-As a sanity check, you can verify your repository only points to remotes in
-`gitlab.org/security` by running: `git remote -v`
-
-- **Contributor:** When developing fixes, you must adhere to these guidelines:
-   - [ ] Your branch name should start with `security-` to prevent unwanted
-     disclosures on the public gitlab.com (this branch name pattern is protected).
-   - [ ] Start your security merge request against master in Gitaly on `gitlab.org/security`
-   - [ ] Keep the MR in WIP state until instructed otherwise.
-   - [ ] Once finished and approved, **DO NOT MERGE**. Merging into master
-     will happen later after the security release is public.
-- **Contributor:** Backport fixes
-   - [ ] Fill out the [version matrix](#version-matrix) above
-     checking if all the versions are affected and require a fix
-- **Contributor:**
-   - [ ] Backport fixes:
-      1. Manually squash all commits in your MR to Gitaly master and force push it to your feature branch on `gitlab.org/security`.
-      1. Cherry pick that squashed commit into a backport MR for all Gitaly target stable branches on `gitlab.org/security`.
-      1. Link all backport MR's into the [above table](#version-matrix).
-      1. Reassign to Maintainer
-- **Maintainer:**
-    - [ ] Review and merge each stable branch merge request
-    - tagging and version bump will be automated by `release-tools`
-
-### Only after the security release occurs and the details are made public
-
-- **Maintainer**:
-   - [ ] Check mirroring status with chatops in slack `/chatops run mirror status`
-   - [ ] Ensure master branch on dev.gitlab.com is synced with gitlab.com:
-      1. `git checkout master`
-      1. `git remote add gitlab.com git@gitlab.com:gitlab-org/gitaly.git`
-      1. `git pull gitlab.com master`
-      1. `git push origin`
-      1. `git remote remove gitlab.com`
-      1. Ensure no origins exist that point to gitlab.com: `git remote -v`
-   - [ ] Merge in request against master on `dev.gitlab.com`
-   - [ ] Bring gitlab.com up to sync with gitlab.org/security:
-      1. `git remote add gitlab.com git@gitlab.com:gitlab-org/gitaly.git`
-      1. `git fetch gitlab.com`
-      1. `git checkout -b gitlab-com-master gitlab.com/master`
-      1. `git merge origin/master` (note: in this repo, origin points to gitlab.org/security)
-      1. `git push gitlab.com gitlab-com-master:master`
-          - Note: If the push fails, try running `git pull gitlab.com master`
-            and then try the push again.
-   - [ ] Upon success, remove the branch and remote:
-      1. `git checkout master`
-      1. `git branch -D gitlab-com-master`
-      1. `git remote remove gitlab.com`
-      1. Ensure no origins exist that point to gitlab.com: `git remote -v`
-   - [ ] There is a good chance the newly patched Gitaly master
-     on `gitlab.com` will need to be used to patch the latest GitLab CE/EE.
-     This will require running the regular release candidate process on gitlab.com.
-   - [ ] Gitaly on GitLab.com uses push mirroring to dev.gitlab.com, if branches
-   are diverged this stops working. Go to `Settings > Repository > Mirroring repositories`
-   to update the mirror. When there's no error after the manual update, it will
-   resume normal operation.
+<!--
+# Read me first!
+
+Create this issue under https://gitlab.com/gitlab-org/security
+
+Set the title to: `Description of the original issue`
+-->
+
+## Prior to starting the security release work
+
+- [ ] Read the [security process for developers] if you are not familiar with it.
+- [ ] Mark this [issue as related] to the Security Release tracking issue. You can find it on the topic of the `#releases` Slack channel.
+- [ ] Run `scripts/security-harness` in your local repository to prevent accidentally pushing to any remote besides `gitlab.com/gitlab-org/security`.
+- Fill out the [Links section](#links):
+  - [ ] Next to **Issue on Gitaly**, add a link to the `gitlab-org/gitaly` issue that describes the security vulnerability.
+  - [ ] Next to **Security Release tracking issue**, add a link to the security release issue that will include this security issue.
+
+## Development
+
+- [ ] Create a new branch prefixing it with `security-`.
+- [ ] Create a merge request targeting `master` on `gitlab.com/gitlab-org/security` and use the [Security Release merge request template].
+- [ ] Follow the same [code review] process: Assign to a reviewer, then to a maintainer.
+
+After your merge request has been approved according to our [approval guidelines], you're ready to prepare the backports
+
+## Backports
+
+- [ ] Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches
+   * At this point, it might be easy to squash the commits from the MR into one
+   * You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation]
+- [ ] Create each MR targeting the stable branch `X-Y-stable`, using the [Security Release merge request template].
+   * Every merge request will have its own set of TODOs, so make sure to complete those.
+- [ ] On the "Related merge requests" section, ensure all MRs are linked to this issue.
+   * This section should only list the merge requests created for this issue: One targeting `master` and the 3 backports.
+
+## Documentation and final details
+
+- [ ] Ensure the [Links section](#links) is completed.
+- [ ] Add the GitLab [versions](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md#versions-affected) and editions affected to the [details section](#details)
+  * The Git history of the files affected may help you associate the issue with a [release](https://about.gitlab.com/releases/)
+- [ ] Fill in any upgrade notes that users may need to take into account in the [details section](#details)
+- [ ] Add the nickname of the external user who found the issue (and/or HackerOne profile) to the Thanks row in the [details section](#details)
+
+## Summary
+
+### Links
+
+| Description | Link |
+| -------- | -------- |
+| Issue on [Gitaly](https://gitlab.com/gitlab-org/gitaly/issues) | #TODO  |
+| Security Release tracking issue | #TODO  |
+
+### Details
+
+| Description | Details | Further details|
+| -------- | -------- | -------- |
+| Versions affected | X.Y  | |
+| Upgrade notes | | |
+| Thanks | | |
 
 [gitaly-ce-version]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/GITALY_SERVER_VERSION
-[gitlab-sec-process]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
+[security process for developers]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
+[secpick documentation]: https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/utilities/secpick_script.md
+[security Release merge request template]: https://gitlab.com/gitlab-org/security/gitaly/blob/master/.gitlab/merge_request_templates/Security%20Release.md
+[code review process]: https://docs.gitlab.com/ee/development/code_review.html
+[approval guidelines]: https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines
+[issue as related]: https://docs.gitlab.com/ee/user/project/issues/related_issues.html#adding-a-related-issue
 
 /label ~"devops::create" ~"group::gitaly" ~"security"
-
-/confidential
diff --git a/.gitlab/merge_request_templates/Security Release.md b/.gitlab/merge_request_templates/Security Release.md
new file mode 100644
index 000000000..cbaf81277
--- /dev/null
+++ b/.gitlab/merge_request_templates/Security Release.md
@@ -0,0 +1,37 @@
+<!--
+# README first!
+This MR should be created on `gitlab.com/gitlab-org/security/gitaly`.
+
+See [the general developer security release guidelines](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md).
+
+-->
+
+## Related issues
+
+<!-- Mention the GitLab Security issue this MR is related to -->
+
+## Developer checklist
+
+- [ ] **On "Related issues" section, write down the [GitLab Security] issue it belongs to (i.e. `Related to <issue_id>`).**
+- [ ] Merge request targets `master`, or `X-Y-stable` for backports.
+- [ ] Milestone is set for the version this merge request applies to. A closed milestone can be assigned via [quick actions].
+- [ ] Title of this merge request is the same as for all backports.
+- [ ] A [CHANGELOG entry](https://docs.gitlab.com/ee/development/changelog.html) is added without a `merge_request` value, with `type` set to `security`
+- [ ] Assign to a reviewer and maintainer, per our [Code Review process].
+- [ ] For the MR targeting `master`:
+  - [ ] Ensure it's approved according to our [Approval Guidelines].
+- [ ] Merge request _must not_ close the corresponding security issue, _unless_ it targets `master`.
+
+**Note:** Reviewer/maintainer should not be a Release Manager
+
+## Maintainer checklist
+- [ ] Correct milestone is applied and the title is matching across all backports
+- [ ] Assigned to `@gitlab-release-tools-bot` with passing CI pipelines and **when all backports including the MR targeting master are ready.**
+
+/label ~security
+
+[GitLab Security]: https://gitlab.com/gitlab-org/security/gitlab
+[approval guidelines]: https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines
+[Code Review process]: https://docs.gitlab.com/ee/development/code_review.html
+[quick actions]: https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics
+