[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Log4j 1.x vulnerability
|
To be honest by using Require-Bundle developers have taken their choice
and should now be punished for it instead of some one else providing
some nice workaround supporting their laziness and/or ignorance.
This whole story greatly shows why import-package is always superior to
require bundle if you consume API.
Anyways I'm sure there will be enough "but the show must go on" +1 so
the only valid alternative is to do it like Ed suggested, making a
bundle that reexports under a given name (and might in this case should
even use Require-Bundle to simply merge the class spaces).
Am 25.01.22 um 19:00 schrieb Dirk Fauth:
Hi,
As Log4j 1.x also has a vulnerability and that project has reached the
EOL there is no official release that could be used to fix that. It
seems QOS has taken over and provides a fixed version:
https://reload4j.qos.ch/ <https://reload4j.qos.ch/>
Unfortunately this can't be used in Eclipse based products to fix the
issue if plug-in developers used Require-Bundle instead of
Import-Package. Reload4j doesn't specify the matching Bundle-SymbolicName.
So my question to the cross project list (as I suppose this issue could
be faced by several projects), would it be possible to re-bundle the
reload4j jar and change the Bundle-SymbolicName to match the old Apache
version? This could then be provided via Orbit for example.
For sure the correct way to solve the problem would be that every
consumer Plug-in of Log4j uses Import-Package instead of Require-Bundle.
But the past can't be changed. And I am looking for a backwards
compatible way that is compliant to the OSS rules.
Any idea or hint is appreciated.
Greez,
Dirk
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
