You can certainly (correctly) argue the technical details about how we often aren't affected by whatever vulnerability that dependabot is warning about,
The problem is that the third-party security scanning tools aren't going to understand that nuance and you will have to keep explaining those technical details every time someone runs some security scanning tools against those artifacts and complains about it. Updating the dependency to the non-vulnerable version can reduce that noise and usually not break compatibility. Also, if we start to ignore the dependabot warnings due to assumptions, we may miss something that is really a problem. Regards, -Eric On Thu, Apr 7, 2022 at 2:51 AM Konrad Windszus <[email protected]> wrote: > I fully agree here. I don’t think dependabot can be controlled via > .asf.yaml yet, so for now we need to disable manually per repo… > > > Am 07.04.2022 um 10:18 schrieb Stefan Seifert <[email protected] > .invalid>: > > > > i agree with robert that probably for most of our modules dependabot is > not helpful (exceptions are the maven plugins and that part of sling > starter which controls which bundles are really deployed at runtime). in > our OSGi world, the dependency just defines the contract against which > package/interface version we compile against. > > > > if possible it would be helpful to disable dependabot for the majority > of git repos to reduce noice, and avoid accidentally raising a dependency > where it's not required to. > > > > stefan > > > > > >> -----Original Message----- > >> From: Eric Norman <[email protected]> > >> Sent: Wednesday, April 6, 2022 8:35 PM > >> To: Sling Developers List <[email protected]> > >> Subject: Re: Fwd: [NOTICE] Dependabot Updates enabled for all projects > >> > >> Perhaps some analysis of whether bumping the dependency version changes > the > >> generated Import-Package instruction can provide some insight regarding > the > >> compatibility. If the new version of the dependency only has changes in > >> packages that we are not directly using then it should be safeish to > >> switch. > >> > >> I would also support changing our process to depend on the lowest > possible > >> version that doesn't have known vulnerabilities. Perhaps with some > >> announcement if there are known compatibility issues. > >> > >> Regards, > >> -Eric > >
