rfc:security-classification

Differences

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

Link to this comparison view

Next revision
Previous revision
rfc:security-classification [2016/11/10 18:00]
krakjoe created
rfc:security-classification [2017/09/22 13:28] (current)
Line 3: Line 3:
   * Date: 2016-11-10   * Date: 2016-11-10
   * Authors: Release Managers   * Authors: Release Managers
-  * Status: ​Voting+  * Status: ​Accepted
   * First Published at: http://​wiki.php.net/​rfc/​security-classification   * First Published at: http://​wiki.php.net/​rfc/​security-classification
  
 At the end of last month, Stas posted to internals with some ideas to reform security issue [[http://​externals.io/​thread/​415|classification]],​ and [[http://​externals.io/​thread/​414|handling]]. At the end of last month, Stas posted to internals with some ideas to reform security issue [[http://​externals.io/​thread/​415|classification]],​ and [[http://​externals.io/​thread/​414|handling]].
  
-Before we can seek to implement changes ​in the process, ​we should seek ratification of the [[:​security|classification]].+Currently any issue that is in theory exploitable with security implications must be treated as a security issue, even if the exploit requires nonsensical settings for a production environment,​ or some other special circumstances. This means that only a few people are able to handle the issue, it means that the fix needs to be merged out of band (from a separate secure repository),​ this results in considerable potential for further mistakes, and exerts disproportionate pressure on a few contributors. 
 + 
 +In short, all the security issues ​can be split into three groups with high, medium and low severity. The essential idea of such classification definitions is to allow different handling depending on the issue severity. In practice, the majority of security issues are purely theoretical,​ or quite hard to trigger. As the risk for such issues is quite low, they can be handled directly ​in the mainstream repository, thus allowing for quality improvement through the usual open QA process
 + 
 +The suggested security issue classifications are based on the real life cases in PHPand are in first place directed to standardize the use cases in PHP. Nevertheless,​ the best practices taking place in various other OSS projects were taken into account. Still, a classification amendment could possibly be required during the course of further work. In that case, the new vote on the modified classification will need to be held. 
 + 
 +In the light of the [[http://​externals.io/​thread/​414|security issue handling discussion]],​ the ratification of the reformed ​[[:​security|classification]] ​is the first step in the direction. We are hoping this classification improves the quality, opens the door for more contributors,​ reduces the workload on a select few contributors,​ and eases our reform of the process that handles genuine security issues. 
 + 
 +Please take the time to read the [[:​security|classification document]] if you haven'​t already, and consider your vote seriously, it is better for everyone if mistakes and inconsistencies (that are likely to be a problem) are dealt with now. 
  
 ==== Voting ==== ==== Voting ====
  
-Voting opened November ​10th for one week, closing November ​17th:+Voting opened November ​11th for one week, closing November ​18th:
  
-<doodle title="​Officially adopt the proposed security issue classification scheme ?" auth="​krakjoe"​ voteType="​single"​ closed="​false">+<doodle title="​Officially adopt the proposed security issue classification scheme ?" auth="​krakjoe"​ voteType="​single"​ closed="​true">
    * Yes    * Yes
    * No    * No
Line 23: Line 32:
  
 //Should the proposal fail to get the required votes, the classification will be reviewed and reformed before the vote is opened again: Consider this notice that there may not be two weeks between the first and subsequent vote.// //Should the proposal fail to get the required votes, the classification will be reviewed and reformed before the vote is opened again: Consider this notice that there may not be two weeks between the first and subsequent vote.//
 +
 +
rfc/security-classification.1478800842.txt.gz · Last modified: 2017/09/22 13:28 (external edit)