well, updating the dependency would not guarantee this, because our bundle contains only a dependency to the latest package version of the 3rdparty dep, not the bundle version which contains the security fix. thus the dependency may be fulfilled with an slightly older bundle that is still vulnerable.
on the other hand updating to the latest version in such a huge step (2.3 to 2.9) may lead to more hassle on target systems where only a new update of our bundle should be deployed and this forces updating other bundles as well (with no really need by the implementation of the bundle). in my pov the osgi package version dependencies are not the right vehicle to enforce deploying 3rdparty bundles without vulnerabilities on the target systems. stefan >-----Original Message----- >From: Eric Norman [mailto:enor...@apache.org] >Sent: Thursday, November 14, 2019 4:14 PM >To: Sling Developers List >Subject: Re: auto-created PRs from github/dependabot for security-related >deps updates > >I think I would prefer that we don't ever depend on any version with known >security issues . So for me, it would be appropriate to take these PRs >seriously and apply the updates as requested. > >What would it hurt to have the next release of the affected sling bundle >depend on the newer minimum version to encourage adoption of the more >secure version of the dependency? > >Regards, >-Eric > >On Thu, Nov 14, 2019 at 2:01 AM Stefan Seifert <sseif...@pro-vision.de> >wrote: > >> github started to auto-create PRs like this: [1] >> >> this feature is nice for standalone projects keeping their deps up-to- >date >> - but in our case it usually means the minimum API version of a >dependency >> we compile against, and not the version of the dependency we are running >in >> our OSGi container with. >> >> so for most our modules (except e.g. maven plugins) i think we do not >want >> this. we cannot switch this feature globally off as we have no access to >> the security area in the github project settings [2]. we could "talk >back" >> to the bot telling him to ignore this actual dependency (but not all for >> the project). >> >> WDYT? >> >> stefan >> >> [1] >> https://github.com/apache/sling-org-apache-sling-models- >jacksonexporter/pull/2 >> [2] >> https://github.com/apache/sling-org-apache-sling-models- >jacksonexporter/network/alerts >> >> >>
