> But we're also talking about the release train repository, which would need a respin.
We may not have to respin the simrel - we can just add newer versions of problematic bundles to the composite and rely on p2 to pick them up at install time?
Will you set the lower bound to force the fixed version and to
disallow the older version?
If only the installer and its product catalogs were involved, I
could fix the problem easily by adding an update site and forcing
the version range to install the fixed version. I wouldn't even
need a new version of Passage to force/fix that...
But we're also talking about the release train repository, which
would need a respin. Unfortunately there are updates in the
SimRel repo after the 2021-12 tag:
Some of those will be needed because the
https://download.eclipse.org/eclipse/updates/4.22-I-builds
repository is gone. Hopefully other projects contributed stable
repositories with unchanging released content rather than pointing
at "moving target" that has changed its content since the release.
If we decide we need to do a respin and we accomplish that, then
EPP needs to respin as well. This will be something the Planning
Council will need to discuss and to decide which actions to take.
Only you know how Passage uses the logging facility to know if
there is in actual fact a risk. I.e., is Passage actually logging
information obtained from an internet connection and is that
actually enabled/activated in the RCP/RAP package itself? I.e.,
does what Jens Lideström outlined apply? (Thanks Jens!) If
not, then perhaps we're unduly alarmed. I could see nothing that
appears to be related to Passage in an IDE into which I installed
Passage, i.e., no preferences, no wizards, no views, nothing
obvious. Is it perhaps the case that the security problems would
only manifest themselves in applications where Passage is deployed
at runtime for licensing control of that application?
Please try to outline the risk factors of Passage's development
tools being installed in a IDE application to help inform the
Planning Council in making a decision.
P.S., Passage in the only component on the 2021-12 train that is
affected; I cannot comment on all Eclipse-distributed content in
general...
Ed, how could we then provide an update for released SimRel
2021-12?
Regards,
AF
P.S. I'm really surprised to have the only component affected
after having org.apache.logging.log4j 2.8.2 published
in Eclipse Orbit starting from 2020-09 (6 releases).
12/12/2021 12:41 PM, Ed Merks пишет:
Just to avoid any confusion such as that which Ed Willink
mentioned, the https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
issue is specifically about the class
org.apache.logging.log4j.core/lookup.JndiLookup.which is not
in a package provided by org.apache.log4j but rather
in a package provided by org.apache.logging.log4j as
illustrated here in a CBI p2 aggregator repo view:
Based on the analysis tool I've
been developing for better managing SimRel, e.g., to provide
traceability and dependency analysis, it's definitely the case
that only Passage depends on this bundle:
Specifically via bundle
requirements (as opposed to package requirements):
Those requirements have no upper
bound, only an inclusive lower bound, such that they will
resolve and use any higher version of
org.apache.logging.log4j. As such, installing Passage with https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository
in the available sites and enabling to use those, does install
the newer version:
The bad news is that the RCP/RAP
package contains Passage and hence the bad version of the
org.apache.logging.log4j bundle.
What's not clear is whether Passage
actually logs messages whose content can be externally
subverted/exploited via contact to the web and whether such
actions are activity is actually enabled by default, e.g., in
the RCP/RAP package...
Regards,
Ed
On 11.12.2021 20:48, Gunnar
Wagenknecht wrote:
Thanks Matthias!
According to Wayne, 2.15 has already been vetted
and is good for use: