I like the idea of explicitly affirming our use of the ASF Vulnerability Policy as well as listing other classes of bugs that are particularly critical for a project like Beam. I think the most valuable thing is having a clear and concise policy for users to understand at a glance. Then we can have a verbose walkthrough for someone implementing the policy.
Kenn On Sat, Jun 16, 2018 at 9:54 AM Chamikara Jayalath <chamik...@google.com> wrote: > While performing a patch release is the correct approach for a critical > fixes I think there are still several points that we might want to discuss > and formalize/document if needed. > > (1) What if there's an ongoing major/minor version release ? > If think patch releases should be independent of any ongoing major/minor > versions releases and should be handled by a separate release manager who > can commit the the time to cut the release immediately. > > (2) What changes should go in ? > Only the fix that addresses the critical issue should go into the patch > release. Any other fixes should be held till the next minor version release. > > (3) What to do with the faulty release ? > We should clearly document the issue with the faulty (non-patched) release > in https://beam.apache.org/get-started/downloads/. This can be > complemented by other announcements (to user list, twitter, for example) > and runner specific solutions (rejecting jobs, warnings for running jobs). > > (4) Voting period and validation. > We are performing the patch on top of an already released branch. So can > we expedite the release validation and voting process ? > > I'm sure there are other points. > > Thanks, > Cham > > On Thu, Jun 14, 2018 at 10:29 PM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> Hi Rafael, >> >> It's a good point but I don't see nothing more to do on our side: if a >> emergency issue is detected, then we have to address it and release a >> fix release (x.y.z where z is the specific release fixing the issue). >> The commitment is a best effort as in all community: if an emergency >> issue is detected, qualified and accepted, then we do our best to >> provide a fix and do the fix release. >> >> So, for me, it's already handled. >> >> By the way, just a quick reminder in term of release: >> >> - now that gradle release seems ok, we resume our release cycle every ~ >> 6 weeks >> - we can cut release anytime if required, especially to address >> emergency issues. >> >> Regards >> JB >> >> On 14/06/2018 22:33, Rafael Fernandez wrote: >> > Hi Beam devs, >> > >> > Emergencies can and will happen. As Apache Beam adoption continues to >> > grow, the user community will naturally expect the Beam developer >> > community to react to critical issues, such as security vulnerabilities >> > in our dependencies. I want to make sure the dev community is in >> > agreement that we follow the ASF Vulnerability Handling processes [1] >> > for such occurrences. >> > >> > >> > In addition, I'd like to discuss cases in which data correctness/loss >> > may warrant an expedited release (i.e., we did not wait 72 hours), as we >> > did in 2.1.1 [2]. Concretely: >> > >> > >> > 1. >> > >> > Do we need to add anything to our project website so the user >> > community knows how we react to such issues? >> > >> > 2. >> > >> > Should we have an entry in the contributor guide to address critical >> > point releases, so we eliminate any guesswork in the event of an >> > emergency? (Example text [3]) >> > >> > >> > Thanks, >> > >> > r >> > >> > >> > [1] >> > >> > _https://apache.org/security/committers.html#vulnerability-handling_ >> > >> > [2] >> https://lists.apache.org/list.html?dev@beam.apache.org:lte=40M:2.1.1 >> > >> > * >> > >> > [3] Example text for the contributor guideline: >> > >> > >> > What requires a critical point release? >> > >> > * >> > >> > A data loss bug >> > >> > * >> > >> > A data corruption bug >> > >> > * >> > >> > A processing correctness bug >> > >> > * >> > >> > For security vulnerabilities, please follow >> > https://apache.org/security/committers.html#vulnerability-handling >> . >> > >> > >> > What do we do a critical point release on? >> > >> > Our first priority is to stop the bleeding. We ought to prioritize a >> > point release for the latest Beam version, based on the release branch, >> > that cherrypicks only the intended fix. >> > >> > * >> > >> > We've done it before! Remember 2.1.1 >> > < >> https://lists.apache.org/list.html?dev@beam.apache.org:lte=40M:2.1.1>? >> > >> > o >> > >> > Since this is a critical release, we can relax our usual 72 hour >> > voting policy. It worked well for 2.1.1, we should make it >> > repeatable: Propose, have PMC folks do due diligence on the >> > request, and sign off. Since this is critical, we may want to >> > have more than one person working on the release. >> > >> > * >> > >> > Once we get it out, the community can discuss which previous >> > releases would benefit from a potential point release. >> > >> > >> > Who proposes a critical point release? >> > >> > Any member of the community. 3 PMC +1 votes are sufficient to get the >> > process rolling. >> > >> > * >> > >> > >> > >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >
