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/10 18:09] – krakjoe | 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:// | ||
- | Before we can seek to implement changes | + | 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, |
+ | |||
+ | In short, all the security issues | ||
+ | |||
+ | The suggested security issue classifications are based on the real life cases in PHP, and are in first place directed to standardize the use cases in PHP. Nevertheless, | ||
+ | |||
+ | In the light of the [[http:// | ||
+ | |||
+ | Please take the time to read the [[: | ||
==== Voting ==== | ==== Voting ==== | ||
- | Voting opened November | + | Voting opened November |
<doodle title=" | <doodle title=" | ||
Line 24: | 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