GitLab/Workflows/Security patches

The following is a proposed Gitlab workflow for managing security/embargoed patches for Wikimedia code. Note that for now, much of the workflow will likely remain the same as the current process, with the addition of using some of Gitlab's features to hopefully improve upon capabilities and efficiency.

Managing security/embargoed patches

 * 1) Upon discovery of any security issues, please review the information and steps within Wikimedia's Reporting Security Bugs documentation.
 * 2) If you have opted to create a Phabricator security report (as opposed to emailing a report to [mailto:security@wikimedia.org security@wikimedia.org]), you will first need to create a Phabricator account to do so if you do not have one.  Once logged into Phabricator, perform a brief search to see if the security issue has already been reported.  If you find no evidence that it has, please submit a secure report via this form.  Submit as much detailed information as possible following the guidelines within the aforementioned Reporting Security Bugs documentation.
 * 3) An important reminder: do not post security reports or related patches to gerrit, github or any other public developer tools, websites, mailing lists, public IRC channels, etc. prior to any responsible disclosure of the underlying security issue.
 * 4) For code which canonically exists within gerrit, please follow the steps below:
 * 5) Develop your patch locally (preferably on a temporary branch) and test it within MediaWiki-Vagrant, MediaWiki-Docker or an an-hoc local development environment.
 * 6) Create a patch file within your working directory by running   (where "Txxxxx" is the Phabricator task id).
 * 7) Upload the patch by attaching it to the relevant Phabricator task as a secure file attachment.  Coordinate with other developers to review your patch by reaching out to them via email, IRC, etc. and then subscribing them to the security task.
 * 8) Again, an important reminder: do not upload the patch publicly to gerrit for review at this time, unless approved to do so by a member of the Security Team.
 * 9) For code which canonically exists within Gitlab, please follow the steps below:
 * 10) If you do not currently have a Wikimedia Gitlab account, you will need to create one under the register tab on the sign-in page.
 * 11) Browse the list of projects and their repositories to find those relevant to the security issue.
 * 12) Once you have found the appropriate project, click on the fork icon located in the top-right corner.
 * 13) For code which canonically exists within Github, please follow the steps below:
 * 14) Likely just use their issue-tracker.
 * 15) If the relevant code repositories exist canonically within another versioning system or repository, please contact [mailto:security@wikimedia.org security@wikimedia.org] for additional guidance.
 * 16) Once the security issue has been privately discussed within Phabricator and all relevant security patches have been tested, reviewed and approved, they should be uploaded to the current deployment server.
 * 17) * Check that the patch applies with
 * 18) * Apply patch with
 * Note that some config files are made public via noc.wikimedia.org; don't put anything non-public in those.
 * 1) Deploy as usual but use   to prevent the automatic logging from revealing too much information about which file or component. Log the deployment manually by saying "!log Deployed patch for Txxxxx" in.
 * 2) Ensure the security patch will be applied to future deployment branches:
 * 3) * The .patch file should be stored on the deployment host under /srv/patches/ /, for whichever branches have the security patch applied.
 * 4) ** Patches to MediaWiki core should be stored in /srv/patches/ /core/
 * 5) ** Patches to extensions should be stored under /srv/patches/ /extensions/ExtensionName.
 * 6) *** Filenames should be prefixed with a 2-digit number to indicate the order in which patches should be applied in the repo. Your file should be prefixed with '01-' if it is the first patch in the directory, or the next highest number if other patches already exist.
 * 7) *** Files should be git committed to the local repository.
 * 8) * Add a note to the relavent ticket saying that you deployed the patch
 * 9) * If security team isn't already aware of what's going on, be sure to inform them you deployed the patch to prevent duplicate effort.
 * 10) Work with the Security Team to make sure the vulnerability is resolved and that your patch makes it into the next security release.
 * 11) Perform any necessary backports within Gerrit to supported release branches (assuming patch applies to previous versions). As an extra step, once the branch is backported to , it can be removed from /srv/patches/ as it will no longer apply to future production release branches.  This will make Release Engineering's life a little easier.
 * 1) Perform any necessary backports within Gerrit to supported release branches (assuming patch applies to previous versions). As an extra step, once the branch is backported to , it can be removed from /srv/patches/ as it will no longer apply to future production release branches.  This will make Release Engineering's life a little easier.


 * 1) Request a CVE, if appropriate. Note the CVE ID on the task and within any relevant security release tasks.

Problem: Submodule security patches not committed
Sometimes you may find a security patch for an extension that has not been committed:

This is normal! The reason for this state is that subsequent updates to the submodules require human intervention to fix merge/rebase conflicts.