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

Reply via email to