Am Mi., 19. Okt. 2022 um 20:05 Uhr schrieb Konrad Windszus <k...@apache.org >:
> Hi, > There are lots of vulnerabilities reported which do not affect our usage > of dependencies. > Therefore I am still in favour of putting the responsibility towards those > who build applications/distributions out of Sling bundles. > While I would favor this solution as well, my question is: Can we build something, which can decide if we are directly affected by a vulnerability (that means by embedding that dependency or at least parts of it)? Only if we can maintain that policy in a reliable way, we can delegate all version updates of not-embedded dependencies to downstream users. > For Sling Starter this is obviously us. > > I would recommend to introduce some automated means (apart from > dependabot) to check for vulnerabilities on all Maven projects which are > not OSGi bundles. > Something like > https://jeremylong.github.io/DependencyCheck/dependency-check-maven/ < > https://jeremylong.github.io/DependencyCheck/dependency-check-maven/> > works for that use case., > > Sure, but on each hit of that plugin "someone" needs to look at the details in a timely fashion and decide if we should do that update or not. Given that Sling has approx 300 github repositories that will be quite a bit of work. > A new policy for not depending on vulnerable dependencies will put a lot > of pressure on us, to release bundles way more often than we currently do > (for no functional benefit). > Agree. 300 repositories and independent artifacts mean quite some work. If the release process is too cumbersome to execute we should think about automating it further. -- Cheers, Jörg Hoh, https://cqdump.joerghoh.de Twitter: @joerghoh