rfc:security-classification

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
Last revisionBoth sides next revision
rfc:security-classification [2016/11/11 12:51] krakjoerfc:security-classification [2016/11/18 07:51] krakjoe
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]].
  
-Current 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.+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. 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.
Line 23: Line 23:
 Voting opened November 11th for one week, closing November 18th: 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
rfc/security-classification.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1