PSR 10 安全问题上报及处理「被拒绝」

简介

处理安全问题有两个方面：一个是安全问题在项目中进行报告和修复的过程，另一个是公众如何了解问题以及可用的补救措施。

PSR 9 解决了前者，而后者，则由 PSR 10 则处理

因此，PSR 10 的目标是定义如何向公众披露安全问题，以及此类披露应遵循何种格式

本文件中的必须，不得，需要，应，不应，应该，不应该，推荐，可能和可选等词按照 RFC 2119 中的描述进行解释

此 PSR 的目标是为研究人员，项目负责人，上游项目负责人和最终用户提供一个规范的结构化的用于披露安全漏洞的流程

每一个项目必须在明显的位置提供一个链接用于披露其安全漏洞。理想情况下，这个位置应该在项目主域名的根页面上

如果是一个较大项目中的子目录，这也可能是一个子域名，如果项目有的专门的披露页面，那么这也被视为是放置链接的好地方

链接可以使用自定义链接引用 php-vuln-disclosure 即

<link rel="php-vuln-disclosure" href="http://example.org/disclosures"/>

项目可以通过创建像 http://security.example.org 这样的专用子域或像 http://example.org/security 这样的顶级目录来突出自己的位置

另外项目也可以简单地引用文件 PSR 10，通过引用 PSR 10 ，一个项目可以声明他们它们遵循本文末尾 默认程序 部分所述的默认程序

项目必须列出在这个参考文献的开始部分记录的变量 ( 即项目名称，项目域名等 ) ，项目可以有选择性的披露那些不是必须的流程中的任何部分

需要注意的是，项目可能没有专用域名。例如在 Github，Bitbucket 或其他服务上托管的项目仍应该在着陆页上有披露流程的引用

例如 http://github.com/example/somelib 应确保默认分支有一个 README 文件，该文件会自动引用披露的流程

如果有必要，项目可以针对不同的主版本号有不同的披露流程。在这种情况下，必须为每个主要版本提供一个URL

如果主要版本不再接收安全修复，那么可以使用 URL 来告知该版本不再接收安全修复

每个项目必须在其安全披露流程中提供一个电子邮件作为联系地址。

项目不得使用联系表单

TODO: 添加这里提到的更多信息 https://groups.google.com/d/msg/php-fig-psr-9-discussion/puGV_X0bj_M/Jr_IAS40StsJ?

如果没有特别指定，contact email address 的值为 security@[project domain]

TODO: 添加上一节中提到的更多内容