You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Michael Marshall <mi...@gmail.com> on 2021/05/27 21:49:31 UTC
[DISCUSS] Propose More Formal Policy for Security Patches and EOL of Versions
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
Re: [DISCUSS] Propose More Formal Policy for Security Patches and EOL
of Versions
Posted by "rxl@apache.org" <ra...@gmail.com>.
LGTM +1
PIP-47 itself also has this scenario consideration.
We can quickly iterate through small versions to quickly
respond to problems that may occur in each major version,
and we can submit patches for major versions at any time.
--
Thanks
Xiaolong Ran
Michael Marshall <mi...@gmail.com> 于2021年5月28日周五 上午5:49写道：
> 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
>
Re: [DISCUSS] Propose More Formal Policy for Security Patches and EOL
of Versions
Posted by Devin Bost <de...@gmail.com>.
+1.
I think these are great suggestions.
--
Devin G. Bost
On Mon, May 31, 2021, 2:30 AM Lari Hotari <lh...@apache.org> wrote:
> > The PMC can also assign members to a security@pulsar.apache.org mailing
> list.
>
> +1 for this plan.
>
> BR, Lari
>
>
> On Fri, May 28, 2021 at 2:24 AM Dave Fisher <wa...@apache.org> wrote:
>
> >
> >
> > 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 security@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
> >
> >
>
Re: [DISCUSS] Propose More Formal Policy for Security Patches and EOL
of Versions
Posted by Lari Hotari <lh...@apache.org>.
> The PMC can also assign members to a security@pulsar.apache.org mailing
list.
+1 for this plan.
BR, Lari
On Fri, May 28, 2021 at 2:24 AM Dave Fisher <wa...@apache.org> wrote:
>
>
> 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 security@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
>
>
Re: [DISCUSS] Propose More Formal Policy for Security Patches and EOL
of Versions
Posted by Enrico Olivelli <eo...@gmail.com>.
Dave
Il giorno ven 28 mag 2021 alle ore 01:24 Dave Fisher <wa...@apache.org>
ha scritto:
>
>
>
> > On May 27, 2021, at 2:49 PM, Michael Marshall <mi...@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 security@pulsar.apache.org mailing list.
This ML does not exist,
can we create it ?
I am part of ZooKeeper PMC, and we are using
security@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
>
Re: [DISCUSS] Propose More Formal Policy for Security Patches and EOL
of Versions
Posted by Dave Fisher <wa...@apache.org>.
> On May 27, 2021, at 2:49 PM, Michael Marshall <mi...@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 security@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
Re: [DISCUSS] Propose More Formal Policy for Security Patches and EOL
of Versions
Posted by Michael Marshall <mi...@gmail.com>.
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 <lh...@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 <mi...@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
>>
>
Re: [DISCUSS] Propose More Formal Policy for Security Patches and EOL
of Versions
Posted by Lari Hotari <lh...@apache.org>.
+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 <mi...@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
>