Thank you for your suggestion, Lari. I opened a PR to add a SECURITY.md file: https://github.com/apache/pulsar/pull/10829. Note that I decided to use 12 months instead of 18 for our support window. I describe why in the PR.
I am hoping this concrete step will push us toward a concrete solution. Please take a look at the PR and provide feedback. Thanks, Michael On Mon, May 31, 2021 at 3:17 AM Lari Hotari <lhot...@apache.org> wrote: > +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 >> >
