From 86eb4e689eae5e42148e21db3fdb4df363394e65 Mon Sep 17 00:00:00 2001
From: Tomas Vik <vicek22@gmail.com>
Date: Tue, 23 Jun 2020 09:28:32 +0000
Subject: [PATCH] Update security release process to reflect the last release.

---
 docs/security-releases.md | 36 ++++++++++++++++++++++--------------
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/docs/security-releases.md b/docs/security-releases.md
index 396f736..bde5267 100644
--- a/docs/security-releases.md
+++ b/docs/security-releases.md
@@ -43,32 +43,38 @@ Please make sure the output of running `scripts/security-harness` is:
 Security harness installed -- you will only be able to push to gitlab.com/gitlab-org/security!
 ```
 
+### Request CVE number
+
+For exploitable security issues, request a CVE number by [creating an issue in `gitlab-org/cves` project](https://gitlab.com/gitlab-org/cves/-/issues/new). Use the assigned CVE number in the [changelog entry](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/master/CHANGELOG.md#security).
+
+Example CVE request: https://gitlab.com/gitlab-org/cves/-/issues/21
+
 ### Branches
 
 The main objective is to release the security fix as a patch of the latest production release and backporting this fix on `master`.
 
 #### Patch release branch
 
-Before starting the development of the fix, create a branch from the latest released tag. You can see the latest released tag as [the extension version in the marketplace](https://marketplace.visualstudio.com/items?itemName=fatihacet.gitlab-workflow). For example, if the latest release has a tag `v.2.2.0` create a branch `security-2-2-0`. This is going to be the target of the security MRs. Push the branch to the security repo.
+Before starting the development of the fix, create a branch from the latest released tag. You can see the latest released tag as [the extension version in the marketplace](https://marketplace.visualstudio.com/items?itemName=fatihacet.gitlab-workflow). For example, if the latest release has a tag `v.2.2.0` create a branch `security-2-2`. This is going to be the target of the security MRs. Push the branch to the security repo.
 
 #### Security fix branch
 
 Your fix is going to be pushed into `security-<issue number>` branch. If you work on issue #9999, you push the fix into `security-9999` branch.
 
 ```sh
-git checkout security-2-2-0
+git checkout security-2-2
 git checkout -b security-9999
 git push security security-9999
 ```
 
 #### Backporting fix branch
 
-This branch is going to serve for merging the security fix back to `master` branch. If you work on issue #9999, you create the `security-9999-backport` branch as follows:
+This branch is going to serve for merging all the security fixes back to `master` branch. If you work on security release v2.2.1, you create the `security-backport-2-2` branch as follows:
 
 ```sh
 git checkout master
-git checkout -b security-9999-backport
-git push security security-9999-backport
+git checkout -b security-backport-2-2
+git push security security-backport-2-2
 ```
 
 ### Development
@@ -77,24 +83,26 @@ Here, the process diverges from the [`gitlab-org/gitlab` security release proces
 
 1. **Before developing the fix, make sure that you've already run the `scripts/security-harness` script.**
 1. Implement the fix and push it to your branch (`security-9999` for issue #9999).
-1. Create an MR to merge `security-9999` to the patch release branch (`security-2-2-0`) and get it reviewed.
+1. Create an MR to merge `security-9999` to the patch release branch (`security-2-2`) and get it reviewed.
 1. Merge the fix (make sure you squash all the MR commits into one).
 
-### Backport the fix to `master`
-
-1. Checkout our backporting branch `git checkout security-9999-backport`
-1. Cherry-pick the fix from the `security-2-2-0` branch.
-1. Create an MR to merge this fix to `master` and get it reviewed
-1. Merge the MR
-
 ### Release the change
 
 - [ ] TODO insert a reference to the release process
 
-Follow the release process to tag a new patch version on the `security-2-2-0` branch and release it. Patch release for tag `v2.2.0` would have version and tag `v2.2.1`.
+Follow the release process to tag a new patch version on the `security-2-2` branch and release it. Patch release for tag `v2.2.0` would have version and tag `v2.2.1`.
 
 Validate that the security issue is fixed in production.
 
+### Backport the fix to `master`
+
+1. Checkout the backporting branch `git checkout security-backport-2-2`
+1. Cherry-pick all the fixes from the `security-2-2` branch.
+1. Create an MR to merge this the backporting branch to `master`
+1. Merge the MR
+
+Example: https://gitlab.com/gitlab-org/security/gitlab-vscode-extension/-/merge_requests/4
+
 ## Push changes back to the [Extension Repo]
 
 1. Push the patch tag to the [Extension Repo]
-- 
GitLab