| Re: [eclipse.org-planning-council] Fwd: [cross-project-issues-dev] Log4j 1.x vulnerability |
On Wed, Feb 23, 2022 at 9:05 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:Hi Ed,
That is a good idea to try. I will try it if we can get ECF's dependency fixed.ECF has hard dependency on zookeeper 3.3.x (https://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.zookeeper/META-INF/MANIFEST.MF#n26) last release of which is from 2011 according to https://zookeeper.apache.org/releases.html . So probably a totally irrelevant feature nowadays.
_______________________________________________On Wed, 23 Feb 2022 at 13:14, Ed Merks <ed.merks@xxxxxxxxx> wrote:_______________________________________________Jonah,
If I understand the details correctly, Xtext still has a dependency on Xpand. Perhaps if we disable the feature included from the Xpand repo while leaving the repo itself available, only the bundles actually needed (by Xtext) would be aggregated and the old log4j would not be aggregated.
I really need to find time to continue the work on the analysis tool, because it can produce the content metadata for an aggregation without doing the actual artifact aggregation/mirroring so that one can quickly (in a minute) try out such things to see what will end up in the repo...
Regards,
Ed
On 23.02.2022 17:32, Jonah Graham wrote:
Hi Planning Council folks,
There are two hard dependencies on the "bad" version of log4j - one from ECF which I hope can easily be resolved, and one from m2t.xpand, which cannot be resolved as m2t.xpand has had no commits in 6 years and has no CI (see Bug 578941).
Can/should we remove m2t.xpand from SimRel - I have a validated patch https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/191151
Jonah
---------- Forwarded message ---------
From: Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
Date: Wed, 23 Feb 2022 at 12:22
Subject: Re: [cross-project-issues-dev] Log4j 1.x vulnerability
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Cc: Dirk Fauth <dirk.fauth@xxxxxxxxxxxxxx>
Hi folks,
The SimRel release will include the reload4j version of the bundle. Most p2 install resolutions will pull in the reload4j version.
However it also includes the 1.2.15 version because of some hard dependencies on the 1.2.15 version (Bug 578940 Bug 578941)
When I do the EPP build I will verify/report whether any of the packages contain the 1.2.15 version.
Jonah
On Wed, 16 Feb 2022 at 03:04, Dirk Fauth via cross-project-issues-dev <cross-project-issues-dev@xxxxxxxxxxx> wrote:
Just as an information for people that did not get the current status via other channels.
The re-bundled version of reload4j is available in the latest stable build of Eclipse Orbit.
Logpresso has added handling for the re-bundled variant and will not detect the vulnerability in its latest version.
_______________________________________________Christian Dietrich <christian.dietrich@xxxxxxxxx> schrieb am Di., 8. Feb. 2022, 17:18:
yes i tried to use the pomDependencies consider features
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190576
https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1782/artifact/releng/repository-all/target/repository/
but i get signing warning and also naming conventions etc
are completely "bogus"
Am 08.02.22 um 17:16 schrieb Ed Merks:
Christian,
I assume it is not jar signed but rather only has an external PGP signature.
Regards,...
Ed
On 08.02.2022 16:48, Christian Dietrich wrote:
is the orginal signing not enhough?
and what about about.html and other eclipse rule foo.
Am 08.02.22 um 16:32 schrieb Matthias Sohn:
I went ahead and pushed the naive addition of reload4j 1.2.19 disguised as bundle org.apache.log4j to Orbitfeel free to change this if someone finds out how to use EBR to only sign the upstream artefact.
-Matthias
On Tue, Feb 8, 2022 at 4:04 PM Dirk Fauth via cross-project-issues-dev <cross-project-issues-dev@xxxxxxxxxxx> wrote:
Well, from my point of view the usage of reload4j is the only backwards compatible solution. Unfortunately not for every case, e.g. too strict version ranges. The solution forward is of course the usage of a log wrapper to decouple development from deployment.
Anyhow I don't know how to add a bundle jar signed and unchanged to Orbit. I am only aware of the re-bundling via EBR. Doing that will cause a change in the jar structure that causes for example logpresso to identify a CVE, although it is fixed. Which is actually only an issue in the detection. But that was one of the reasons why I contacted the reload4j project to change the base to avoid the re-bundling.
Anyone who knows how to only sign and publish to Orbit without re-bundling?
_______________________________________________Ed Merks <ed.merks@xxxxxxxxx> schrieb am Di., 8. Feb. 2022, 15:54:
_______________________________________________Dirk,
Thanks. That's really great! It would be great for this release cycle if it were jar signed and available from Orbit so that we could ship it with 2022-03...
There are people who are concerned:
https://www.eclipse.org/forums/index.php/mv/msg/1109656/1849775/#msg_1849775
Though I'm not sure if they would consider the problem being fixed in 1.2.19 a fact and even if its a fact if it would be a fact that matters...
Regards,
Ed
On 08.02.2022 15:48, Dirk Fauth via cross-project-issues-dev wrote:
Hi,
I got in contact with the reload4j team. They changed the Bundle-SymbolicName to org.apache.log4j and fixed several OSGi meta data related issues in the meanwhile. Today they published 1.2.19 which should work as a drop-in replacement in Eclipse based applications where Require-Bundle was used. My local tests worked so far.
That said, re-bundling for Orbit should not be necessary as reload4j could directly be consumed via Maven Central.
Just wanted to keep you updated.
Greez,Dirk
Ed Willink <ed.willink@xxxxxxxxx> schrieb am Mi., 26. Jan. 2022, 13:47:
Hi
On 26/01/2022 07:48, Christoph Läubrich wrote:
> Why not using SLF4J in all places and let the user choose the
> implementation with their favorite CVEs?
Use of SLF4J has been suggested before and so I tried to be a good
Eclipse citizen. My failed attempts are described in:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559532
If SLF4J is to be used, can someone please ensure that the platform is
fit for purpose and that there is a good tutorial on how to do really
boring logging.
Regards
Ed Willink
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
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
_______________________________________________ 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
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
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
_______________________________________________ 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
Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle, Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef SchuermannAufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), Harald Goertz, Eric SwehlaSitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen (Germany)Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621
_______________________________________________ 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
_______________________________________________ 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
Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle, Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef SchuermannAufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), Harald Goertz, Eric SwehlaSitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen (Germany)Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621_______________________________________________
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
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
_______________________________________________ eclipse.org-planning-council mailing list eclipse.org-planning-council@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
--Aleksandar KurtakovRed Hat Eclipse Team