Move most of this to https://github.com/php/policies as per Policies RFC

Author: derickr

SECURITY.md

@@ -1,127 +1,4 @@
-# Vulnerability Disclosure Policy
-
-*This document was originally published at <https://wiki.php.net/security>.*
-
-## Introduction
-
-For the sake of our users, we classify some of the issues found in PHP
-as "security issues". This document is intended to explain which issues
-are thus classified, how we handle those issues and how to report them.
-
-## Classification
-
-We classify as security issues bugs that:
-
-- allow users to execute unauthorized actions
-- cross security boundaries
-- access data that is not intended to be accessible
-- severely impact accessibility or performance of the system
-
-The purpose of this classification is to alert the users and the
-developers about the bugs that need to be prioritized in their handling.
-
-We define three categories of security issues, by their severity,
-described below. Please note that this categorization is in many aspects
-subjective, so it ultimately relies on the judgement of the PHP
-developers.
-
-### High severity
-
-These issues may allow:
-
-- third party to compromise any, or most installations of PHP
-- the execution of arbitrary code
-- disabling the system completely
-- access to any file a local PHP user can access.
-
-The issue can be triggered on any, or on most typical installations, and
-does not require exotic and non-recommended settings to be triggered.
-
-This category also includes issues that can be triggered in code or
-functions known to be frequently used (session, json, mysql, openssl,
-etc.) during typical usage, and that require settings or configurations
-that may not be strictly the best practice, but are commonly used.
-
-This category also may include issues that require special code or code
-pattern if such code or pattern is present in many popular libraries.
-
-This kind of issues usually requires a CVE report.
-
-### Medium severity
-
-These issues may have the same potential to compromise an installation
-as a high severity issue, but may also require:
-
-- an extension that is not commonly used
-- a particular type of configuration that is used only in narrow
-  specific circumstances
-- relies on old version of a third-party library being used
-- code, or patterns of code, that are known to be used infrequently
-- code that is very old, or extremely uncommon (and so is used
-  infrequently)
-
-This kind of issues usually will have a CVE number, unless the required
-configuration is particularly exotic to the point it's not practically
-usable.
-
-### Low severity
-
-This issue allows theoretical compromise of security, but practical
-attack is usually impossible or extremely hard due to common practices
-or limitations that are virtually always present or imposed.
-
-This also includes problems with configuration, documentation, and other
-non-code parts of the PHP project that may mislead users, or cause them
-to make their system, or their code less secure.
-
-Issues that can trigger unauthorized actions that do not seem to be
-useful for any practical attack can also be categorized as low severity.
-
-Security issues, that are present only in unstable branches, belong to
-this category, too. Any branch that has no stable release, is per se not
-intended for the production use.
-
-Low severity issues usually do not need to have CVE and may, at the
-discretion of the PHP developers, be disclosed publicly before the fix
-is released or available.
-
-### Not a security issue
-
-We do not classify as a security issue any issue that:
-
-- requires invocation of specific code, which may be valid but is
-  obviously malicious
-- requires invocation of functions with specific arguments, which may
-  be valid but are obviously malicious
-- requires specific actions to be performed on the server, which are
-  not commonly performed, or are not commonly permissible for the user
-  (uid) executing PHP
-- requires privileges superior to that of the user (uid) executing PHP
-- requires the use of debugging facilities - ex. xdebug, var_dump
-- requires the use of settings not recommended for production - ex.
-  error reporting to output
-- requires the use of non-standard environment variables - ex.
-  USE_ZEND_ALLOC
-- requires the use of non-standard builds - ex. obscure embedded
-  platform, not commonly used compiler
-- requires the use of code or settings known to be insecure
-- requires the use of FFI
-- requires an open_basedir bypass
-
-## Handling issues
-
-High and medium severity fixes are merged into a private security repository,
-and then merged to the main repository before the release is tagged.
-
-Low severity fixes are merged immediately after the fix is available and
-handled like all regular bugs are handled consequently. However, release
-managers may choose to pull those fixes into the RC branch after the
-branch is created, and also backport them into a security-only release
-branch.
-
-## FAQ
-
-### How do I report a security issue?
+# Reporting Security Issues
 
 Please report security vulnerabilities on GitHub at:
 <https://github.com/php/php-src/security/advisories/new>
@@ -134,35 +11,7 @@ Vulnerability reports remain private until published. When published, you will
 be credited as a contributor, and your contribution will reflect the MITRE
 Credit System.
 
-### What do you consider a responsible disclosure?
-
-Please report the issue as described above. Please communicate with
-the developers about when the fix will be released - usually it's the
-next monthly release after the bug was reported. Some issues can take
-longer. After the fix is released (releases usually happen on Thursdays)
-please feel free to disclose the issue as you see fit.
-
-### What if I think it's a security issue but the developers disagree?
-
-Please read the above and try to explain to us why it fits the
-description.
-
-### What if the developers still don't think it's a security issue?
-
-We'll have to agree to disagree.
-
-### The bug I submitted was classified as "not a security issue." You don't believe it's real?
-
-It has nothing to do with the bug being real or its importance to
-you. It just means it does not fit our specific definitions for issues
-that we will handle in a special way. We fix a lot of non-security bugs
-and pull requests are always welcome.
-
-### But you classified bug #424242 as a security issue, but not this one?!
-
-Each bug usually has its aspects, if a short discussion does not
-yield agreement we'd rather do more fixing and less arguing.
-
-### Do you pay bounties for security issues?
+# Vulnerability Policy
 
-PHP is a volunteer project. We have no money, thus we can't pay bounties.
+Our full policy is described at
+https://github.com/php/policies/blob/main/security-classification.rst