You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2022/10/19 15:28:12 UTC
Discuss policy for updating dependencies
Hi,
in light of https://issues.apache.org/jira/browse/SLING-11623 I think
its worth to have a hopefully brief discussion about our dependency
update policy.
https://cwiki.apache.org/confluence/display/SLING/Dependabot captures
what we said in the past and I think this is a good guideline, keeping
the dependency at the lowest required.
However :) with security issues in dependencies like the above, we leave
all the responsibility on our users. Clearly, we don't want any of our
users to run with known security issues, so if we update our
dependencies to versions without known issues, we help our customers as
they have to update the dependencies as well. It makes the world a
little bit safer and avoids all these continuous scanning reports.
I'm currently torn between the two, slightly prefering to update
dependencies in case of security issues.
Regards
Carsten
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Discuss policy for updating dependencies
Posted by Robert Munteanu <ro...@apache.org>.
Hi,
On Wed, 2022-10-19 at 17:28 +0200, Carsten Ziegeler wrote:
> Hi,
>
> in light of https://issues.apache.org/jira/browse/SLING-11623 I think
> its worth to have a hopefully brief discussion about our dependency
> update policy.
>
> https://cwiki.apache.org/confluence/display/SLING/Dependabot captures
> what we said in the past and I think this is a good guideline,
> keeping
> the dependency at the lowest required.
>
> However :) with security issues in dependencies like the above, we
> leave
> all the responsibility on our users. Clearly, we don't want any of
> our
> users to run with known security issues, so if we update our
> dependencies to versions without known issues, we help our customers
> as
> they have to update the dependencies as well. It makes the world a
> little bit safer and avoids all these continuous scanning reports.
>
> I'm currently torn between the two, slightly prefering to update
> dependencies in case of security issues.
I think there is a middle ground here. We can update the pom dependency
but manually set the import ranges with bnd.
It is more error-prone and I don't think we should do it lightly, which
is why it is a good fit for security updates only.
FWIW, the recent commons-text update did update the version ranges, so
we can't rely on projects no updating their version ranges if nothing
changed, most of them use the project version for exported packages.
We could couple this with something like the ossindex-maven-plugin [1]
to fail the build for CVEs of a certain severity, with the possible
addition of an exclude list of CVEs that we are sure do not affect us.
Thoughts?
Robert
[1]: https://sonatype.github.io/ossindex-maven/
Re: Discuss policy for updating dependencies
Posted by Carsten Ziegeler <cz...@apache.org>.
It seems we all agree that we don't want our users to run vulnerable
dependencies. Yet, we do not agree to support our users in that respect.
Imho, there is no point to guarantee that a Sling module still runs with
an old, insecure version of a dependency. However, we make it the
default to allow this.
I guess we can close this discussion as we are not moving anywhere.
Thanks
Carsten
Am 19.10.2022 um 17:28 schrieb Carsten Ziegeler:
> Hi,
>
> in light of https://issues.apache.org/jira/browse/SLING-11623 I think
> its worth to have a hopefully brief discussion about our dependency
> update policy.
>
> https://cwiki.apache.org/confluence/display/SLING/Dependabot captures
> what we said in the past and I think this is a good guideline, keeping
> the dependency at the lowest required.
>
> However :) with security issues in dependencies like the above, we leave
> all the responsibility on our users. Clearly, we don't want any of our
> users to run with known security issues, so if we update our
> dependencies to versions without known issues, we help our customers as
> they have to update the dependencies as well. It makes the world a
> little bit safer and avoids all these continuous scanning reports.
>
> I'm currently torn between the two, slightly prefering to update
> dependencies in case of security issues.
>
> Regards
> Carsten
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Discuss policy for updating dependencies
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday, 28 October 2022 18:36:07 CEST Jörg Hoh wrote:
> I want to add another aspect to this discussion.
>
> In many of out integration tests we use the versions of additional bundles
> to deploy into the IT from the pom. That means that in all of these ITs we
> deliberately test against old(er) versions of our bundles (except the test
> subject, of course); that might be a combination of bundle many consumers
> won't use anymore, and which leaves some gaps in test coverage for new
> features.
Such gaps can easily be closed.
The modules¹ which use Testing PaxExam for ITs use (test) dependencies
decoupled from the (compile) versions in the POM. See second point below
Features².
Regards,
O.
[1] https://github.com/apache/sling-org-apache-sling-testing-paxexam/network/
dependents
[2] https://sling.apache.org/documentation/development/testing-paxexam.html#features
> Am Mi., 19. Okt. 2022 um 17:28 Uhr schrieb Carsten Ziegeler <
>
> cziegeler@apache.org>:
> > Hi,
> >
> > in light of https://issues.apache.org/jira/browse/SLING-11623 I think
> > its worth to have a hopefully brief discussion about our dependency
> > update policy.
> >
> > https://cwiki.apache.org/confluence/display/SLING/Dependabot captures
> > what we said in the past and I think this is a good guideline, keeping
> > the dependency at the lowest required.
> >
> > However :) with security issues in dependencies like the above, we leave
> > all the responsibility on our users. Clearly, we don't want any of our
> > users to run with known security issues, so if we update our
> > dependencies to versions without known issues, we help our customers as
> > they have to update the dependencies as well. It makes the world a
> > little bit safer and avoids all these continuous scanning reports.
> >
> > I'm currently torn between the two, slightly prefering to update
> > dependencies in case of security issues.
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe
> > cziegeler@apache.org
Re: Discuss policy for updating dependencies
Posted by Jörg Hoh <jh...@googlemail.com.INVALID>.
I want to add another aspect to this discussion.
In many of out integration tests we use the versions of additional bundles
to deploy into the IT from the pom. That means that in all of these ITs we
deliberately test against old(er) versions of our bundles (except the test
subject, of course); that might be a combination of bundle many consumers
won't use anymore, and which leaves some gaps in test coverage for new
features.
Am Mi., 19. Okt. 2022 um 17:28 Uhr schrieb Carsten Ziegeler <
cziegeler@apache.org>:
> Hi,
>
> in light of https://issues.apache.org/jira/browse/SLING-11623 I think
> its worth to have a hopefully brief discussion about our dependency
> update policy.
>
> https://cwiki.apache.org/confluence/display/SLING/Dependabot captures
> what we said in the past and I think this is a good guideline, keeping
> the dependency at the lowest required.
>
> However :) with security issues in dependencies like the above, we leave
> all the responsibility on our users. Clearly, we don't want any of our
> users to run with known security issues, so if we update our
> dependencies to versions without known issues, we help our customers as
> they have to update the dependencies as well. It makes the world a
> little bit safer and avoids all these continuous scanning reports.
>
> I'm currently torn between the two, slightly prefering to update
> dependencies in case of security issues.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
>
--
Cheers,
Jörg Hoh,
https://cqdump.joerghoh.de
Twitter: @joerghoh
Re: Discuss policy for updating dependencies
Posted by Eric Norman <er...@gmail.com>.
>
> There are lots of vulnerabilities reported which do not affect our usage
> of dependencies.
While this is probably true, is this an argument you want to keep having
over and over again? I have found some security focused folks don't trust
the engineering assurances that we are not affected. Especially when
their automated scanning tools keep flagging the problems.
It's probably easier in the long run to just conceded the point the
security tools are flagging, update the dependencies and move on.
Regards,
Eric
On Wed, Oct 19, 2022 at 11:05 AM Konrad Windszus <kw...@apache.org> wrote:
> 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.
> 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.,
>
> 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).
>
> However, what is documented at
> https://cwiki.apache.org/confluence/display/SLING/Dependabot probably
> needs to be documented on our web site for consumers as well, so that the
> expectations can be managed.
>
> Regards,
> Konrad
>
>
> > On 19. Oct 2022, at 17:28, Carsten Ziegeler <cz...@apache.org>
> wrote:
> >
> > Hi,
> >
> > in light of https://issues.apache.org/jira/browse/SLING-11623 I think
> its worth to have a hopefully brief discussion about our dependency update
> policy.
> >
> > https://cwiki.apache.org/confluence/display/SLING/Dependabot captures
> what we said in the past and I think this is a good guideline, keeping the
> dependency at the lowest required.
> >
> > However :) with security issues in dependencies like the above, we leave
> all the responsibility on our users. Clearly, we don't want any of our
> users to run with known security issues, so if we update our dependencies
> to versions without known issues, we help our customers as they have to
> update the dependencies as well. It makes the world a little bit safer and
> avoids all these continuous scanning reports.
> >
> > I'm currently torn between the two, slightly prefering to update
> dependencies in case of security issues.
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe
> > cziegeler@apache.org
>
>
Re: Discuss policy for updating dependencies
Posted by Konrad Windszus <kw...@apache.org>.
>
>
>> 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.
>
My proposal was to only enable that check for non-OSGi bundles (which is just a handful of those 300).
For embedded dependencies we need to find some other solution (don’t know if there is already something out there).
Konrad
Re: Discuss policy for updating dependencies
Posted by Jörg Hoh <jh...@googlemail.com.INVALID>.
Am Mi., 19. Okt. 2022 um 20:05 Uhr schrieb Konrad Windszus <kwin@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
Re: Discuss policy for updating dependencies
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday, 19 October 2022 20:05:03 CEST Konrad Windszus wrote:
> Hi,
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.
> 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.,
>
> 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).
>
> However, what is documented at
> https://cwiki.apache.org/confluence/display/SLING/Dependabot probably needs
> to be documented on our web site for consumers as well, so that the
> expectations can be managed.
+1 to everything above
In addition there are dependencies with older versions not vulnerable.
Depending on the lowest possible version gives us more flexibility.
Regards,
O.
> Regards,
> Konrad
>
> > On 19. Oct 2022, at 17:28, Carsten Ziegeler <cz...@apache.org> wrote:
> >
> > Hi,
> >
> > in light of https://issues.apache.org/jira/browse/SLING-11623 I think its
> > worth to have a hopefully brief discussion about our dependency update
> > policy.
> >
> > https://cwiki.apache.org/confluence/display/SLING/Dependabot captures what
> > we said in the past and I think this is a good guideline, keeping the
> > dependency at the lowest required.
> >
> > However :) with security issues in dependencies like the above, we leave
> > all the responsibility on our users. Clearly, we don't want any of our
> > users to run with known security issues, so if we update our dependencies
> > to versions without known issues, we help our customers as they have to
> > update the dependencies as well. It makes the world a little bit safer
> > and avoids all these continuous scanning reports.
> >
> > I'm currently torn between the two, slightly prefering to update
> > dependencies in case of security issues.
> >
> > Regards
> > Carsten
Re: Discuss policy for updating dependencies
Posted by Konrad Windszus <kw...@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.
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.,
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).
However, what is documented at https://cwiki.apache.org/confluence/display/SLING/Dependabot probably needs to be documented on our web site for consumers as well, so that the expectations can be managed.
Regards,
Konrad
> On 19. Oct 2022, at 17:28, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Hi,
>
> in light of https://issues.apache.org/jira/browse/SLING-11623 I think its worth to have a hopefully brief discussion about our dependency update policy.
>
> https://cwiki.apache.org/confluence/display/SLING/Dependabot captures what we said in the past and I think this is a good guideline, keeping the dependency at the lowest required.
>
> However :) with security issues in dependencies like the above, we leave all the responsibility on our users. Clearly, we don't want any of our users to run with known security issues, so if we update our dependencies to versions without known issues, we help our customers as they have to update the dependencies as well. It makes the world a little bit safer and avoids all these continuous scanning reports.
>
> I'm currently torn between the two, slightly prefering to update dependencies in case of security issues.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
Re: Discuss policy for updating dependencies
Posted by Eric Norman <en...@apache.org>.
I would also like to reiterate that if what you depend on is using proper
semantic package versioning and the version numbers you depend on have not
changed, then there would be no harm in updating the minimum version in
your pom to the newer one. The output in your manifest would be identical.
How would you feel about some new tooling that is similar to
the bnd-baseline-maven-plugin that would compare the Import-Package entries
to check if any of the imported package ranges has changed since the last
released version? If the minimum version of some imported package is now
larger, then perhaps it should require a bump to the minor segment of the
bundle version number and fail the build until that happens? That should
make the dependabot pull requests that trigger that scenario fail to build
without manual intervention. Then the dependabot pull requests that don't
trigger that scenario could be approved and merged.
Regards,
Eric
On Wed, Oct 19, 2022 at 10:56 AM Eric Norman <en...@apache.org> wrote:
> I would generally prefer that no dependencies have known security issues.
> Basically, my position on this is the same as it was ~3 years ago from the
> thread at [1].
>
> Also, I'd agree with what was reported at [2] that it doesn't make sense
> to depend on versions that have been declared as EOL when there is a newer
> alternative that is still maintained.
>
> 1. https://lists.apache.org/thread/jhj626gn9xzng3bdxkmyx6ozyvcg7rlq
> 2. https://issues.apache.org/jira/browse/SLING-11621
>
> Regards,
> Eric
>
> On Wed, Oct 19, 2022 at 8:28 AM Carsten Ziegeler <cz...@apache.org>
> wrote:
>
>> Hi,
>>
>> in light of https://issues.apache.org/jira/browse/SLING-11623 I think
>> its worth to have a hopefully brief discussion about our dependency
>> update policy.
>>
>> https://cwiki.apache.org/confluence/display/SLING/Dependabot captures
>> what we said in the past and I think this is a good guideline, keeping
>> the dependency at the lowest required.
>>
>> However :) with security issues in dependencies like the above, we leave
>> all the responsibility on our users. Clearly, we don't want any of our
>> users to run with known security issues, so if we update our
>> dependencies to versions without known issues, we help our customers as
>> they have to update the dependencies as well. It makes the world a
>> little bit safer and avoids all these continuous scanning reports.
>>
>> I'm currently torn between the two, slightly prefering to update
>> dependencies in case of security issues.
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe
>> cziegeler@apache.org
>>
>
Re: Discuss policy for updating dependencies
Posted by Eric Norman <en...@apache.org>.
I would generally prefer that no dependencies have known security issues.
Basically, my position on this is the same as it was ~3 years ago from the
thread at [1].
Also, I'd agree with what was reported at [2] that it doesn't make sense to
depend on versions that have been declared as EOL when there is a newer
alternative that is still maintained.
1. https://lists.apache.org/thread/jhj626gn9xzng3bdxkmyx6ozyvcg7rlq
2. https://issues.apache.org/jira/browse/SLING-11621
Regards,
Eric
On Wed, Oct 19, 2022 at 8:28 AM Carsten Ziegeler <cz...@apache.org>
wrote:
> Hi,
>
> in light of https://issues.apache.org/jira/browse/SLING-11623 I think
> its worth to have a hopefully brief discussion about our dependency
> update policy.
>
> https://cwiki.apache.org/confluence/display/SLING/Dependabot captures
> what we said in the past and I think this is a good guideline, keeping
> the dependency at the lowest required.
>
> However :) with security issues in dependencies like the above, we leave
> all the responsibility on our users. Clearly, we don't want any of our
> users to run with known security issues, so if we update our
> dependencies to versions without known issues, we help our customers as
> they have to update the dependencies as well. It makes the world a
> little bit safer and avoids all these continuous scanning reports.
>
> I'm currently torn between the two, slightly prefering to update
> dependencies in case of security issues.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
>