The ASF generally mandates a min of 3 days for votes on release candidates. This can be significantly shortened if there is a security issue that needs a quick release. With Podlings, they typically require 2 rounds of voting (PPMC and then the Incubator PMC) but again if a podling needs a quick release they can forewarn the PPMC and Incubator PMC about the need for a curtailed voting schedule.
In my experience, fixes for Zero Day exploits are only a small proportion of the security related fixes that get made. This is somewhat tangential to what this discussion is about. On Fri, 24 Jan 2025 at 22:34, Jochen Theodorou <blackd...@gmx.org.invalid> wrote: > > Maybe one more thing we should think about. What if there is a security > issue, the response of the podling is good and the issue gets fixed very > fast. And can only be fixed by a new release. But then the incubator > finds issues with the release and the release issues cannot be fixed > right away. I doubt the security process describes this kind of scenario. > > > On 24.01.25 17:32, PJ Fanning wrote: > > Thanks Calvin for your response. Maybe we could start by having the ASF > > Security team track progress on reported issues - as they already do. In > > the Incubator public reporting, we would not disclose anything other than > > self reporting that the PPMC feels confident that they are in a good > > position to deal with issues and follow the ASF Security process. > > > > Maybe the Incubator shepherds could independently check this too. > > > > I'm open to forming a consensus on the right level of reporting. > > > > When it comes to graduating, I would like to be able to vote -1 for > > podlings who appear not to be following the security process. > > > > > > > > On Fri 24 Jan 2025, 16:11 Calvin Kirs, <k...@apache.org> wrote: > > > >> I completely agree with this proposal, even though some podlings rarely > >> encounter security issues during incubation. (This may change as they > >> transition to TLP status and gain more visibility.) However, understanding > >> and recognizing the importance of security issues is also something > >> podlings need to learn during the incubation period. > >> > >> If podlings are required to report existing security issues and their > >> progress, how should this be done? Through private@i.a.o? Currently, our > >> reports are fully public. > >> > >> In the final board submission, the Incubator will also need to provide a > >> consolidated private report on security issues. This report should include > >> the number of security issues and identify any podlings that are in an > >> unhealthy state regarding their handling of security problems. > >> > >> That said, the successful submission of this report will likely rely > >> heavily on the efforts of shepherds and mentors. > >> > >> On Fri, Jan 24, 2025 at 9:36 PM PJ Fanning <fannin...@gmail.com> wrote: > >> > >>> Hi everyone, > >>> > >>> I didn't follow up on this when I raised it in December 2023. I'd like > >>> to propose it again. > >>> Basically, the idea is that the podling reports, that we do every 3 > >>> months, would have a question about whether the podling believes that > >>> they are being sufficiently responsive to issues raised on their > >>> private mailing list (particularly security issues). There would maybe > >>> also be a reminder about the ASF policies related to dealing with > >>> disclosures about vulnerabilities [1]. > >>> I would also like to see a section about this in the Graduation Report > >>> - having podlings declare that they have been and intend to continue > >>> to be responsive to disclosures about vulnerabilities. This is covered > >>> by QU30 in the Project Maturity Model [2] but I wonder if the text > >>> could be adjusted to also mention the need to be responsive to > >>> vulnerability reports. > >>> With efforts like the CRA [3] and other regulatory requirements around > >>> the world, this area is becoming even more important. > >>> > >>> What do people think? > >>> > >>> Thanks, > >>> PJ > >>> > >>> [1] https://www.apache.org/security/ > >>> [2] > >>> > >> https://community.apache.org/apache-way/apache-project-maturity-model.html#quality > >>> [3] https://en.wikipedia.org/wiki/Cyber_Resilience_Act > >>> > >>> On Wed, 13 Dec 2023 at 16:21, Craig Russell <apache....@gmail.com> > >> wrote: > >>>> > >>>> Hi PJ, > >>>> > >>>> I agree that there should be a section in podlings' reports that > >>> highlights <private/> security issues. > >>>> > >>>> Regards, > >>>> Craig > >>>> > >>>>> On Dec 13, 2023, at 05:22, PJ Fanning <fannin...@apache.org> wrote: > >>>>> > >>>>> Hi everyone, > >>>>> > >>>>> I'm wondering if podlings should include some details about their > >>>>> security issues [1] in their 3 podling reports. We won't want to > >>>>> release information about any security issues that are still under > >>>>> investigation or where the fix is not yet released. I still think > >>>>> there is little harm in podlings giving high level numbers and maybe > >>>>> some indication of how quickly security issues are being dealt with. > >>>>> > >>>>> I've seen evidence that some TLPs are unaware of the importance of > >>>>> dealing quickly with security reports and I think the Incubator team > >>>>> could help with ensuring that podlings are aware of the requirements. > >>>>> > >>>>> I will certainly be having a close look at a podling's record of > >>>>> handling security reports when it comes to discussions about > >>>>> graduation. > >>>>> > >>>>> I'm wondering if we could have some consensus on what is expected of > >>> podlings. > >>>>> > >>>>> Regards, > >>>>> PJ > >>>>> > >>>>> [1] https://www.apache.org/security/ > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>>>> For additional commands, e-mail: general-h...@incubator.apache.org > >>>>> > >>>> > >>>> Craig L Russell > >>>> c...@apache.org > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>>> For additional commands, e-mail: general-h...@incubator.apache.org > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>> For additional commands, e-mail: general-h...@incubator.apache.org > >>> > >>> > >> > >> -- > >> Best wishes！ > >> CalvinKirs > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
