rfc:security-classification

This is an old revision of the document!


PHP RFC: Security Issue Classification

At the end of last month, Stas posted to internals with some ideas to reform security issue classification, and 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.

Before we can seek to implement changes in the process that handles security issues, we should seek ratification of the reformed classification.

Please take the time to read the 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.

We are hoping this classification 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.

Voting

Voting opened November 10th for one week, closing November 17th:

Officially adopt the proposed security issue classification scheme ?
Real name Yes No
ab (ab)  
bishop (bishop)  
cmb (cmb)  
colinodell (colinodell)  
dmitry (dmitry)  
krakjoe (krakjoe)  
lcobucci (lcobucci)  
lstrojny (lstrojny)  
mariano (mariano)  
mbeccati (mbeccati)  
mgocobachi (mgocobachi)  
ryat (ryat)  
sammyk (sammyk)  
stas (stas)  
svpernova09 (svpernova09)  
tpunt (tpunt)  
trowski (trowski)  
yohgaki (yohgaki)  
Count: 18 0

There is no change to the language, however, since this is an important issue, we are going to require a super majority of 2/3+1.

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.

Note: Should we discover, during the course of our work that the classification requires amendment, we will once again hold a vote.

rfc/security-classification.1478857927.txt.gz · Last modified: 2017/09/22 13:28 (external edit)