Add latest changes from gitlab-org/gitlab@master

2 files changed, 44 insertions, 42 deletions

diff --git a/.gitlab/issue_templates/Security developer workflow.md b/.gitlab/issue_templates/Security developer workflow.md
index e06a6fb0cff..1b6a1f87216 100644
--- a/.gitlab/issue_templates/Security developer workflow.md
+++ b/.gitlab/issue_templates/Security developer workflow.md
@@ -1,60 +1,59 @@
 <!--
 # Read me first!
 
-Create this issue under https://dev.gitlab.org/gitlab/gitlabhq
+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
+## Prior to starting the security release work
 
 - [ ] Read the [security process for developers] if you are not familiar with it.
-- [ ] Link to the original issue adding it to the [links section](#links)
-- [ ] Run `scripts/security-harness` in the CE, EE, and/or Omnibus to prevent pushing to any remote besides `dev.gitlab.org`
-- [ ] Create a new branch prefixing it with `security-`
-- [ ] Create a MR targeting `dev.gitlab.org` `master`
-- [ ] Add a link to this issue in the original security issue on `gitlab.com`.
+- [ ] Link this issue in the Security Release issue on GitLab.com. You can find this issue in the topic of the `#releases` channel.
+- [ ] Add a link to the confidential `gitlab-org/gitlab` issue describing the vulnerability next to **Original issue** in the [links table](#links).
+- [ ] Add a link to the confidential `gitlab-org/gitlab` Security release issue next to **Security release issue** in the [links table](#links).
+- [ ] Run `scripts/security-harness` in your local repository to prevent accidentally pushing to any remote besides `gitlab.com/gitlab-org/security`.
 
-#### Backports
+## Development
 
-- [ ] 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.
-- [ ] Make sure all MRs have a link in the [links section](#links)
+- [ ] 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.
 
-[secpick documentation]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#secpick-script
+After your merge request has being approved according to our [approval guidelines], you're ready to prepare the backports
+
+## Backports
 
-#### Documentation and final details
+- [ ] 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.
+- [ ] Make sure all MRs are linked in the [Links section](#links)
+
+## Documentation and final details
 
-- [ ] Check the topic on #releases to see when the next release is going to happen and add a link to the [links section](#links)
-- [ ] Add links to this issue and your MRs in the description of the security release issue
+- [ ] Ensure the [Links section](#links) is completed.
 - [ ] Find out the versions affected (the Git history of the files affected may help you with this) and add them to the [details section](#details)
 - [ ] Fill in any upgrade notes that users may need to take into account in the [details section](#details)
 - [ ] Add Yes/No and further details if needed to the migration and settings columns 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)
 - [ ] Once your `master` MR is merged, comment on the original security issue with a link to that MR indicating the issue is fixed.
 
-### Summary
+## Summary
 
-#### Links
+### Links
 
 | Description | Link |
 | -------- | -------- |
 | Original issue   | #TODO  |
 | Security release issue   | #TODO  |
 | `master` MR | !TODO   |
-| `master` MR (EE) | !TODO   |
 | `Backport X.Y` MR | !TODO   |
 | `Backport X.Y` MR | !TODO   |
 | `Backport X.Y` MR | !TODO   |
-| `Backport X.Y` MR (EE) | !TODO   |
-| `Backport X.Y` MR (EE) | !TODO   |
-| `Backport X.Y` MR (EE) | !TODO   |
 
-#### Details
+### Details
 
 | Description | Details | Further details|
 | -------- | -------- | -------- |
@@ -65,6 +64,9 @@ Set the title to: `Description of the original issue`
 | Thanks | | |
 
 [security process for developers]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
-[RM list]:  https://about.gitlab.com/release-managers/
+[secpick documentation]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#secpick-script
+[security Release merge request template]: https://gitlab.com/gitlab-org/security/gitlab/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
 
 /label ~security
diff --git a/.gitlab/merge_request_templates/Security Release.md b/.gitlab/merge_request_templates/Security Release.md
index 42314f9b2dd..6556b9c9a72 100644
--- a/.gitlab/merge_request_templates/Security Release.md
+++ b/.gitlab/merge_request_templates/Security Release.md
@@ -1,31 +1,27 @@
 <!--
 # README first!
-This MR should be created on `dev.gitlab.org`.
+This MR should be created on `gitlab.com/gitlab-org/security/gitlab`.
 
 See [the general developer security release guidelines](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md).
 
-This merge request _must not_ close the corresponding security issue _unless_ it
-targets master.
-
-When submitting a merge request for CE, a corresponding EE merge request is
-always required. This makes it easier to merge security merge requests, as
-manually merging CE into EE is no longer required.
-
 -->
+
 ## Related issues
 
 <!-- Mention the issue(s) this MR is related to -->
 
 ## Developer checklist
 
-- [ ] Link to the developer security workflow issue on `dev.gitlab.org`
-- [ ] MR targets `master`, or `X-Y-stable` for backports
-- [ ] Milestone is set for the version this MR applies to
-- [ ] Title of this MR is the same as for all backports
+- [ ] Link this MR in the `links` section of the related issue on [GitLab Security].
+- [ ] Merge request targets `master`, or `X-Y-stable` for backports.
+- [ ] Milestone is set for the version this merge request applies to.
+- [ ] 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`
-- [ ] Add a link to this MR in the `links` section of related issue
-- [ ] Set up an EE MR (always required for CE merge requests): EE_MR_LINK_HERE
-- [ ] Assign to a reviewer (that is not a release manager)
+- [ ] Assign to a reviewer and maintainer, per our [Code Review process].
+- [ ] If this merge request targets `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
 
 ## Reviewer checklist
 
@@ -33,3 +29,7 @@ manually merging CE into EE is no longer required.
 - [ ] Assigned to `@gitlab-release-tools-bot` with passing CI pipelines
 
 /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