Dave Il giorno ven 28 mag 2021 alle ore 01:24 Dave Fisher <w...@apache.org> ha scritto: > > > > > 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.
This ML does not exist, can we create it ? I am part of ZooKeeper PMC, and we are using secur...@zookeeper.apache.org for this purpose and it works pretty well. Can you please start a discussion inside Pulsar PMC to create that ML ? I will be also interested in being subscribed Enrico > > 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 >
