Hi Beam-devs! There is also the consideration of which releases to fix. I am familiar with Apache Hadoop and there may be a "stable", "beta" and "alpha" release. Usually security fixes are ported to one or more of those branches.
Cheers Ravi On Sat, Jun 16, 2018 at 2:43 PM, Kenneth Knowles <k...@google.com> wrote: > 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 >>> >>
