> On May 27, 2021, at 2:49 PM, 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.
Looking at this as a PMC member who has had to triage security for a very
widely downloaded and old project codebase (OpenOffice) there is some record
keeping that the PMC should do in private to track vulnerabilities before they
are CVEs.
The PMC can also assign members to a secur...@pulsar.apache.org mailing list.
The PMC can request a private SVN repository and/or private Confluence Wiki for
keeping records and assuring that such missed back ports are less likely.
(Private Git limited to the PMC is not currently possible (it is an Infra
wish)) Doing this allows even “non-technical” PMC members to help manage the
CVE process.
All The Best,
Dave
>
> I look forward to your thoughts and suggestions.
>
> Thanks,
>
> Michael Marshall
