That sounds reasonable. We can call put these bits in the docs so the community doesn't feel we don't care about contrib extensions at all.
On Wed, Sep 6, 2023 at 4:14 AM Gian Merlino <g...@apache.org> wrote: > I think it would be OK to have a policy that contrib extension dependencies > are not proactively screened for CVEs. If we adopt such a policy, we do > need to make it clear to people that they should do their own screening of > any contrib extensions they use. > > However, we can't extend that policy to saying we don't take responsibility > for security of contrib extensions at all. If there is a vulnerability in > the code of a contrib extension itself, then we are obligated to fix it. If > we receive a vulnerability report about a contrib extension, including a > report about an issue with one of its dependencies (via the process at > https://www.apache.org/security/#reporting-a-vulnerability) then we should > take it seriously and investigate. This is the cost of having the code > exist at all and be part of our source releases. We can only avoid _those_ > costs by removing an extension completely. > > On Mon, Sep 4, 2023 at 3:02 AM Abhishek Agarwal <abhis...@apache.org> > wrote: > > > Hello all > > What is our current policy about addressing CVEs in contrib extensions if > > we have one? As of now, before the release, the release manager will > either > > try to fix the CVEs or add a suppression if applicable. Unless any > > developer has done that same work before the release process begins. > This, > > however, is a tedious exercise for the release manager and for us > > maintainers. With contrib extensions added to the mix, there is a huge > > surface area for us to cover when it comes to managing CVEs in > > dependencies. > > > > I propose excluding contrib extensions from our CVE checks so that RM can > > ignore those CVEs during the release. We don't ship the contrib > extensions > > in distribution anyway, so it seems like a reasonable stance to me. > > >
