security_fixes

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
security_fixes [2015/12/16 12:37] kaplansecurity_fixes [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Handling security fixes ====== ====== 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, but only how to merge patch once you have a working one. +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. 
  
 ===== Verify ===== ===== Verify =====
  
-  - Post the patch to the bugs.php.net to the issue where it was reported. If the patch is big, use the "[[https://help.github.com/articles/creating-gists/|secret gist]]" function on github.com. Do not use github pulls.+  - Post the patch to the bugs.php.net to the issue where it was reported. If the patch is big, use the "[[https://help.github.com/articles/creating-gists/|secret gist]]" function on github.com. **Do not** use github pull requests, those are public!
   - Ask the original reporter to confirm that the patch works.   - Ask the original reporter to confirm that the patch works.
   - Assign the bug to yourself so that it is clear you are working on it now.    - Assign the bug to yourself so that it is clear you are working on it now. 
-  - Verify that the tests accompanying the patch and other relevant tests work. Note that you can not use CI for that for now.+  - 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 locallyRasmus' Vagrant box setup may help: https://github.com/rlerdorf/php7dev
  
 ===== Commit ===== ===== Commit =====
Line 15: Line 15:
   - 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.   - 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.
   - Create the NEWS entry for the fix and all other file updates that are necessary (tests, UPGRADING, etc.).    - Create the NEWS entry for the fix and all other file updates that are necessary (tests, UPGRADING, etc.). 
-  - 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 pverflow and introduced proper boundary checking"+  - 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"
   - Verify that the tests still run (the repository may have changed while you were working on the patch and waiting for feedback).   - Verify that the tests still run (the repository may have changed while you were working on the patch and waiting for feedback).
   - Push the branch into the security repo.    - Push the branch into the security repo. 
   - Notify the RM for the branches affected about the existence of the pending fix, preferably well in advance of the release date.   - Notify the RM for the branches affected about the existence of the pending fix, preferably well in advance of the release date.
-  - Leave the note on the bug that the fix has been pushed to the security repo and the branch name.+  - Leave the note on the bug that the fix has been pushed to the security repo and the commit hash or branch name.
   - 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.    - 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. 
  
Line 26: Line 26:
 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.  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. 
  
-  - 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. +  - 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
   - 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.    - 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. 
   - Push the result into the main repository   - Push the result into the main repository
   - Verify that CI tests run clearly and that NEWS are updated for all relevant versions (including higher versions).    - Verify that CI tests run clearly and that NEWS are updated for all relevant versions (including higher versions). 
   - 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).    - 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). 
-  - 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, do not commit too early so that time between bug being disclosed and the fix released would be minimal. +  - 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. 
  
 ===== CVEs ===== ===== CVEs =====
security_fixes.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1