GitLab/Workflows/Security patches

Policy Migration status Workflows Project setup assumptions Registering an account on GitLab Hosting a project on GitLab Pipeline conversion Mirroring projects Configuring CI Publishing documentation Code review Making a merge request Squashing Managing security patches Deploying services to production Gerrit to GitLab Localization updates wikitech:GitLab GitLab implementation

1. If you do not currently have a Wikimedia developer account, you will need to create one and then sign into Gitlab. If you've already created a Phabricator account, chances are you've already completed this step.
2. Once signed into GitLab with your account, click on the Groups > Explore Groups option and then click the New Group button.
3. Create a new group named Security-Txxxxx where Txxxxx is the Phabricator task id of the task you created to track this security issue. Ensure that the visibility of this group is Private. Under the Members section of the group, invite relevant members of the Security Team and others who might assist with code review. Only add as many users as necessary - the fewer users the better.
4. Next, browse the list of projects and their repositories to find those relevant to the security issue.
5. Once you have found and navigated to the appropriate project, click on the Fork icon located in the top-right corner.
6. By default, GitLab will want to fork the repository into your user's namespace. Instead, select the private Security-Txxxxx group listed below the pre-selected user namespace. This may take GitLab some time to complete depending upon the size of the repository. To verify the new fork, examine the url in your web browser - it should contain the path: security-txxxxx/name-of-the-project.
7. Assuming you have a working security patch from the initial steps section, you'll likely want to add any relevant ssh keys to GitLab so you can easily push changes to this newly-forked repository. You can create a new development branch if you'd like, but since this is a forked project under a private group namespace, you can simply work from the main branch.
8. Now apply your security patch within a cloned repository of your private forked repository. You may also add relevant individuals, including members of the Security Team, to further review or monitor the security patch within Gitlab. Let any relevant CI/CD pipelines run to validate the code prior to any additional approvals or merges back to the main project.
9. Once the security patch has been tested and deployed to production (see manual steps below), a merge request should be created to merge all relevant changes from the security issue project fork back to the original project's repository. This should involve a merge from a main branch to a main branch. This can be accomplished by choosing the Merge Requests menu item within the right navigation and completing the steps. You should compare the changes and select the option to squash commits when the request is accepted. For the merge request title and/or description, SECURITY: fix for Txxxxx should suffice. This process can also be used to backport to any relevant release branches in addition to the main branch.
10. An important reminder: do not create or attempt to merge a merge request until the security issue has been properly disclosed, which a member of the Security Team should be able to verify.
11. Once the merge request has been approved and merged, the forked project and private group should be deleted. For the project, this can be accomplished by navigating to Settings > Advanced > Expand > Delete project. For the private group, this can be accomplished by navigating to Groups > Your Groups > the relevant private group > Settings > Advanced > Remove group.