On 26.11.2024 16:19, Jörg Hoh wrote:
Hi,
I agree to Eric, that we should try to reduce the noise of security
scanners, which just scan build-time dependencies instead of runtime
dependencies, as in most java projects they are identical. Here in the OSGI
world these versions can be different and in reality often are.
I also see Julian's position about testing against old versions of
dependencies; IIRC I had that case once that all unit tests passed on a
bundle, but during runtime functionality failed, because a newer but
compatible dependency had a minimal change in semantics. We would have
detected that behavior in the unit tests if we would have had the
dependencies updated.
For that my
+1
to change the policy and encourage people to update dependencies to the
oldest version with no known vulnerability.
In a certain other project, we are still suffering from not updating
early (Lucene and Guava come to mind, but things that were EOLd ages ago
are a problem as well (commons-collections3).
So maybe the recommendation needs to be tuned a bit:
- use the *newest* version that doesn't change OSGi package versions (so
is supposed to be compatible)
and
- act early when a component has an EOL date, and the replacement isn't
backwards compatible
Also maybe have a maven toggle to test with "newest of all dependencies"
as well.
Best regards, Julian
