debian-mirror-gitlab/.gitlab/issue_templates/Security developer workflow.md at 099204596373f5eb3fa0e88c3e929ebc3428b409

Sruthi Chandran 0329642ba5 New upstream version 11.8.0

2019-03-02 22:35:43 +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 targetting 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 targetting 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
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