debian-mirror-gitlab/.gitlab/issue_templates/Security developer workflow.md at 9314e91d66ea871acd87187b24ec871eb2ba9856

Sruthi Chandran 400b49096b New upstream version 12.0.8

2019-09-04 21:01:54 +05:30

Read the security process for developers if you are not familiar with it.
Link to the original issue adding it to the links section
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.

Once the MR is ready to be merged, create MRs targeting the last 3 releases, plus the current RC if between the 7th and 22nd of the month.
- 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

Check the topic on #security to see when the next release is going to happen and add a link to the links section
Add links to this issue and your MRs in the description of the security release issue
Find out the versions affected (the Git history of the files affected may help you with this) and add them to the details section
Fill in any upgrade notes that users may need to take into account in the details section
Add Yes/No and further details if needed to the migration and settings columns in the details section
Add the nickname of the external user who found the issue (and/or HackerOne profile) to the Thanks row in the details section
Once your master MR is merged, comment on the original security issue with a link to that MR indicating the issue is fixed.

/label ~security