rfc:security-classification
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:security-classification [2016/11/11 12:04] – ab | rfc:security-classification [2016/11/11 12:51] – krakjoe | ||
---|---|---|---|
Line 8: | Line 8: | ||
At the end of last month, Stas posted to internals with some ideas to reform security issue [[http:// | At the end of last month, Stas posted to internals with some ideas to reform security issue [[http:// | ||
- | 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, | + | 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, |
- | 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 big part of security issues are rather pure theoretical or quite hard to trigger. As the risk on such issues is quite low, they can be handled directly in the mainstream repository, thus allowing for a 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 |
- | The suggested security issue classifications are in first place directed to standardize the use cases in PHP. Nevertheless, | + | The suggested security issue classifications |
- | Before we can seek to implement changes in the process that handles | + | In the light of the [[http:// |
Please take the time to read the [[: | Please take the time to read the [[: | ||
- | We are hoping this classification opens the door for more contributors, | ||
==== Voting ==== | ==== Voting ==== | ||
- | Voting opened November | + | Voting opened November |
<doodle title=" | <doodle title=" | ||
Line 34: | Line 33: | ||
//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.// | ||
- | 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.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1