Handling security fixes

This is the instruction for how to handle security fixes for currently active PHP branches. Note this is not an instruction on how to fix bugs in PHP (if you're reading this, you already supposed to know that, if you do not, please seek help from one of the experienced PHP group members), but only how to merge patch once you have a working one.

1. Post the patch to the bugs.php.net to the issue where it was reported. If the patch is big, use the “secret gist” function on github.com. Do not use github pull requests, those are public!
2. Ask the original reporter to confirm that the patch works.
3. Assign the bug to yourself so that it is clear you are working on it now.
4. Verify that the tests accompanying the patch and other relevant tests work. Note that you can not use CI for that for now, you'll have to run the tests locally. Rasmus' Vagrant box setup may help: https://github.com/rlerdorf/php7dev

1. If you have access to PHP security repository, please proceed below. Otherwise, please contact somebody that does and send them the patch, or contact security@php.net if you do not know anybody who does. Since edits on security bugs are reported to the security list, adding note to the bug works too.
2. Make a branch for the patch in a lowest version where it is relevant. If the patch is significantly different in other versions (such as 5.5 from 7.x), make the branches for all versions.
3. Create the NEWS entry for the fix and all other file updates that are necessary (tests, UPGRADING, etc.).
4. Commit the patch to the branch. Do not push the branch to main repo or your own public fork. Ensure that the commit message mentions bug number and contains a short description of what was done, e.g.: “Fixed bug #44666: removed buffer overflow and introduced proper boundary checking”.
5. Verify that the tests still run (the repository may have changed while you were working on the patch and waiting for feedback).
6. Push the branch into the security repo.
7. Notify the RM for the branches affected about the existence of the pending fix, preferably well in advance of the release date.
8. Leave the note on the bug that the fix has been pushed to the security repo and the commit hash or branch name.
9. If desired, especially if working on multiple patches, copies of current master branch (i.e. PHP-5.6 or PHP-7.0) and/or release branch (PHP-5.6.7 or PHP-7.0.2) may be used to merge the patches. These branches should be pushed only to the security repo. Never push those into any of the public repos.

Releases are usually tagged every 4 weeks on Tuesday and released on Thursday, so to know the date when the next release will be tagged, take 4 weeks from the last release date and count two days back. Please watch announcement on the list and contact RMs when in doubt since release dates can be changed in some circumstances.

1. On the day of tagging or the day immediately before (consult with RM about relative timezones, etc.) merge the branches for the security fix into the main repository. Please note that if the fix is not the same for all active branches and you need to merge multiple branches, you will need to merge both the fix branch *and* the lower branch into higher branch. Optionally, RM can choose to merge the fixes, please communicate.
2. Set the bug on bugs.php.net into public status. Note that doing that before pushing will allow the relevant bug to be auto-closed.
3. Push the result into the main repository
4. Verify that CI tests run clearly and that NEWS are updated for all relevant versions (including higher versions).
5. Verify that the bug on bugs.php.net is indeed closed (may take several minutes for the bots to catch up). If it did not happen, close the bug manually (quoting the commit highly recommended if it wasn't attached automatically).
6. After done merging all pending security fixes you had, notify the RMs. The RMs may have to pull the fixes into the release branches, so please choose the time that will allow them to do so before it is time to tag. However, try not to commit too early so that time between bug being disclosed and the fix released would be minimal.

CVE handling procedures TBD.

Some useful info:

Request a CVE Identifier - https://cve.mitre.org/cve/request_id.html

Introduction to CVE Identifier Reservation The basic process is:

1. There is a request for one or more CVE-ID number(s).
2. MITRE reserves the CVE-ID number(s) and provides the number(s) to the requester, and creates “blank,” content-free CVE(s) on the CVE Web site.
3. The requester shares the CVE-ID number(s) with all parties involved in the disclosure.
4. The requester includes the CVE-ID number(s) in the vulnerability advisory.
5. The requester makes the CVE-ID(s) public and notifies MITRE.
6. MITRE updates the CVE-ID(s) on the CVE Web site to provide the details.