<!-- <!--
# Read me first! # 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` 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. - [ ] 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) - [ ] 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 the CE, EE, and/or Omnibus to prevent pushing to any remote besides `dev.gitlab.org` - [ ] Run `scripts/security-harness` in your local repository to prevent accidentally pushing to any remote besides `gitlab.com/gitlab-org/security`.
- [ ] Create a new branch prefixing it with `security-` - Fill out the [Links section](#links):
- [ ] Create a MR targeting `dev.gitlab.org` `master` - [ ] Next to **Issue on GitLab**, add a link to the `gitlab-org/gitlab` issue that describes the security vulnerability.
- [ ] Add a link to this issue in the original security issue on `gitlab.com`. - [ ] Next to **Security Release tracking issue**, add a link to the security release issue that will include this security issue.
#### Backports ## Development
- [ ] Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches - [ ] Create a new branch prefixing it with `security-`.
- [ ] At this point, it might be easy to squash the commits from the MR into one - [ ] Create a merge request targeting `master` on `gitlab.com/gitlab-org/security` and use the [Security Release merge request template].
- You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation] - [ ] Follow the same [code review process]: Assign to a reviewer, then to a maintainer.
- [ ] 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)
[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
#### Documentation and final details ## 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.
- [ ] Check the topic on #releases to see when the next release is going to happen and add a link to the [links section](#links) ## Documentation and final details
- [ ] 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) - [ ] 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) - [ ] 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 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) - [ ] 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. - [ ] 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 | | Description | Link |
| -------- | -------- | | -------- | -------- |
| Original issue | #TODO | | Issue on [GitLab](https://gitlab.com/gitlab-org/gitlab/issues) | #TODO |
| Security release issue | #TODO | | Security Release tracking issue | #TODO |
| `master` MR | !TODO |
| `master` MR (EE) | !TODO | ### Details
| `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
| Description | Details | Further details| | Description | Details | Further details|
| -------- | -------- | -------- | | -------- | -------- | -------- |
...@@ -65,6 +62,10 @@ Set the title to: `Description of the original issue` ...@@ -65,6 +62,10 @@ Set the title to: `Description of the original issue`
| Thanks | | | | Thanks | | |
[security process for developers]: 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
[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
[issue as related]: https://docs.gitlab.com/ee/user/project/issues/related_issues.html#adding-a-related-issue
/label ~security /label ~security
<!-- <!--
# README first! # 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). 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 ## Related issues
<!-- Mention the issue(s) this MR is related to --> <!-- Mention the GitLab Security issue this MR is related to -->
## Developer checklist ## Developer checklist
- [ ] Link to the developer security workflow issue on `dev.gitlab.org` - [ ] **Make sure this merge request mentions the [GitLab Security] issue it belongs to (i.e. `Related to <issue_id>`).**
- [ ] MR targets `master`, or `X-Y-stable` for backports - [ ] Merge request targets `master`, or `X-Y-stable` for backports.
- [ ] Milestone is set for the version this MR applies to - [ ] Milestone is set for the version this merge request applies to. A closed milestone can be assigned via [quick actions].
- [ ] Title of this MR is the same as for all backports - [ ] 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` - [ ] 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 - [ ] Assign to a reviewer and maintainer, per our [Code Review process].
- [ ] Set up an EE MR (always required for CE merge requests): EE_MR_LINK_HERE - [ ] For the MR targeting `master`:
- [ ] Assign to a reviewer (that is not a release manager) - [ ] Ping appsec team member who created the issue and ask for a non-blocking review with `Please review this MR`.
- [ ] Ensure it's approved according to our [Approval Guidelines].
- [ ] Merge request _must not_ close the corresponding security issue, _unless_ it targets `master`.
## Reviewer checklist **Note:** Reviewer/maintainer should not be a Release Manager
## Maintainer checklist
- [ ] Correct milestone is applied and the title is matching across all backports - [ ] Correct milestone is applied and the title is matching across all backports
- [ ] Assigned to `@gitlab-release-tools-bot` with passing CI pipelines - [ ] Assigned to `@gitlab-release-tools-bot` with passing CI pipelines
/label ~security /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
File mode changed from 100644 to 100755
File mode changed from 100644 to 100755