@@ -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).
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`
