+1 , Thanks for the suggestion, Michael. I hope we can get the security policy documented for Apache Pulsar asap.
GitHub suggests adding a SECURITY.md file to the repository. When committers go to https://github.com/apache/pulsar/security , the UI suggests "Setup a security policy": [image: image.png] Clicking on the button takes to editing a SECURITY.md file [image: image.png] This is also documented in https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository . Perhaps this could be the way how to document the security policy in Apache Pulsar? The GitHub provided template has these sections: - Supported Versions - Reporting a Vulnerability There are a lot more extensive templates available such as https://github.com/Trewaters/security-README/blob/master/security.md . It seems that some projects also document it in SECURITY.md how to securely use the product. One example is SECURITY.md in TensorFlow, https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md . Michael, could you create a PR for the SECURITY.md file? It might be easier to revisit the details of the security policy in a PR review. BR, Lari On Fri, May 28, 2021 at 12:49 AM Michael Marshall <mikemars...@gmail.com> wrote: > Hi Pulsar Community, > > > I would like to discuss defining and documenting a process for an official > Pulsar version EOL policy. This process will help users know when the > version they are running will no longer be supported with security patches. > > After the recent announcement of CVE-2021-22160, I looked on the official > pulsar website for a documented process describing which branches will > receive security patches when vulnerabilities are discovered. I could not > find a process on the website. I did find a policy for handling version EOL > described in PIP-47, though ( > > https://github.com/apache/pulsar/wiki/PIP-47%3A-Time-Based-Release-Plan#what-is-our-eol-policy > ). > Based on the policy, I would have expected a release of 2.6.4 with the > security patch for CVE-2021-22160, but that patch was not cherry-picked to > branch-2.6 until this week after the publication of the CVE, and we’re only > just now starting the process to release 2.6.4. > > I think it’s also relevant to consult the ASF guide for vulnerability > handling. The process is outlined here: > https://www.apache.org/security/committers.html. Regarding releasing > fixes, > it only mentions the following: > > > 15. The project team creates a release that includes the fix. > > > 16. The project team announces the vulnerability. The vulnerability > announcement should be sent after, or at the same time as, the release > announcement to the following destinations. > > Given the above information, I think it would be appropriate to have a > policy that ensures all active/supported branches receive security patches > before a CVE is announced. > > I propose we adopt a policy similar to Apache Spark’s policy, which is to > provide security fixes for feature branches for at least 18 months after > the initial minor version release: > https://spark.apache.org/versioning-policy.html. If we apply this policy > to > Pulsar, 2.6.x will receive security patches until December 2021 (2.6.0 was > released in June 2020). > > When I brought this up at the community meeting today, Matteo mentioned > supporting releases for a year. I am open to that time frame as well. My > main objective is to have a policy that is documented and easily discovered > by our users. > > I look forward to your thoughts and suggestions. > > Thanks, > > Michael Marshall >
