debian-mirror-gitlab/.gitlab/issue_templates/Security developer workflow.md
2021-11-11 11:23:49 +05:30

4.5 KiB

Prior to starting the security release work

  • Read the security process for developers if you are not familiar with it.
  • Make sure the issue really needs to follow the security release workflow.
    • Verify if the issue you're working on gitlab-org/gitlab is confidential, if it's public fix should be placed on GitLab canonical and no backports are required.
    • If the issue you're fixing doesn't appear to be something that can be exploited by a malicious person and is instead simply a security enhancement do not hesitate to ping @gitlab-com/gl-security/appsec to discuss if the issue can be fixed in the canonical repository.
  • IMPORTANT: Mark this issue as linked to the Security Release Tracking Issue. You can find it on the topic of the #releases Slack channel. This issue MUST be linked for the release bot to know that the associated merge requests should be merged for this security release.
  • Fill out the Links section:
    • Next to Issue on GitLab, add a link to the gitlab-org/gitlab issue that describes the security vulnerability.
  • Add one of the ~severity::x labels to the issue and all associated merge requests.

Development

  • Run scripts/security-harness in your local repository to prevent accidentally pushing to any remote besides gitlab.com/gitlab-org/security.
  • Create a new branch prefixing it with security-.
  • Create a merge request targeting master on gitlab.com/gitlab-org/security and use the Security Release merge request template.

After your merge request has been approved according to our approval guidelines and by a team member of the AppSec team, you're ready to prepare the backports

Backports

  • Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches
    • The 3 stable branches correspond to the versions in the title of the Security Release Tracking Issue.
    • 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 to-dos, so make sure to complete those.
  • On the "Related merge requests" section, ensure that 4 merge requests are associated: The one targeting master and the 3 backports.
  • If this issue requires less than 4 merge requests, post a message on the Security Release Tracking Issue and ping the Release Managers.

Documentation and final details

  • Ensure the Links section is completed.
  • Add the GitLab versions and editions affected to the details section
    • The Git history of the files affected may help you associate the issue with a release
  • 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

Summary

Description Link
Issue on GitLab #TODO

Details

Description Details Further details
Versions affected X.Y
GitLab EE only Yes/No
Upgrade notes
GitLab Settings updated Yes/No
Migration required Yes/No
Thanks

/label ~security