debian-mirror-gitlab/.gitlab/issue_templates/Security developer workflow.md at 11e9def0a325839034f02b5f1501de0f33a7c20c

Abhijith PA 715c4ade07 New upstream version 11.8.10+dfsg

2019-05-30 16:15:17 +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