[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] Log4j 1.x vulnerability
|
Dirk,
I think rebundling to provide a drop-in replacement would be
good. I suppose if there were some reason one could not or should
not do that (a reason that I cannot think of), one could always
create a bundle that imports all the packages and exports them all
in order to create a drop-in replacement. But that's unneeded
overhead. In any case, it would be good to have a drop-in
replacement. I could use one for Xcore and I'm sure Xtext and
others could and would use one too...
Thanks,
Ed
On 25.01.2022 19:00, Dirk Fauth wrote:
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:
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,
_______________________________________________
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