Hi Christoph, That sounds reasonable to me and an interesting solution. Could SimRel include it as a sub/composite repo? Would adding it to the released composite repos cause the Check for Updates to remove (prompt to remove) the problematic jars?
Is that a p2 site you can craft for this issue? My p2 knowledge isn't sufficient for such a task. Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Mon, 13 Dec 2021 at 11:30, Christoph Läubrich <lae...@laeubi-soft.de> wrote: > Hi Ed, > > I wonder if it would not be possible to publish a general purpose > "CVE mitigation" Updatesite everyone could add to an existing eclipse > install. > > Such an Updatesite could contain a Unit for a given CVE (e.g. > CVE-2021-44228 in this case) that defines a negative requirement on any > affected version (in this case any org.apache.logging.log4j with version > range < 2.15). > > What will happen then is that P2 will give the user the choice to > install this mitigation unit and uninstall > > a) the dangerous bundle > b) any dependent and affected unit (passage in this case) > > from the current IDE. > > Once an Update is in place, passage could be installed (e.g. with a > separate update-site) again including a fixed version of the problematic > dependecy. > > Even though such a site would currently need some kind of handcrafted > metadata, we could enhance this so we probably once have some automatic > import of CVE from public databases and automatic notification of users > about new CVE affecting their IDE. > > Including such a site in a target platform of a build could effectively > fail the build (and make projects automatically aware of new problems) > as they arise, also preventing one from including problematic > dependencies in the future. > > What do you think does this sounds reasonable? > > Am 12.12.21 um 14:07 schrieb Ed Merks: > > Alexander, > > > > 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... > > > > Regards, > > Ed > > > > On 12.12.2021 11:04, Alexander Fedorov wrote: > >> Passage Team is working to provide Eclipse Passage 2.2.1 that will > >> consume fixed logger from > >> > https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository > >> > >> > >> 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: > >>>> https://www.eclipse.org/lists/eclipse.org-committers/msg01333.html > >>>> > >>>> -Gunnar > >>>> > >>>> -- > >>>> Gunnar Wagenknecht > >>>> gun...@wagenknecht.org, http://guw.io/ > >>>> > >>>> > >>>> > >>>>> On Dec 11, 2021, at 20:36, Matthias Sohn <matthias.s...@gmail.com> > >>>>> wrote: > >>>>> > >>>>> On Sat, Dec 11, 2021 at 11:35 AM Gunnar Wagenknecht > >>>>> <gun...@wagenknecht.org> wrote: > >>>>> > >>>>> Alexander, > >>>>> > >>>>>> On Dec 11, 2021, at 10:16, Alexander Fedorov > >>>>>> <alexander.fedo...@arsysop.ru> wrote: > >>>>>> It would be great to learn vulnerability clean-up process with > >>>>>> Eclipse Orbit team to then apply it to Eclipse Passage. > >>>>> > >>>>> > >>>>> There is no Orbit team. Orbit is driven by project committers > >>>>> using/needing libraries in Orbit. > >>>>> I encourage the Eclipse Passage project to submit a Gerrit > >>>>> review for a newer version. > >>>>> > >>>>> > >>>>> considering the buzz around this vulnerability I went ahead and > >>>>> pushed an update to log4j 2.15 for orbit > >>>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188768 > >>>>> note that the required clearlydefined score isn't reached yet, if > >>>>> this doesn't change soon > >>>>> maybe someone can contribute the missing information to > >>>>> clearlydefined or > >>>>> we file CQs to get the license approval for the new version > >>>>> > >>>>> You can also try a new way as described by Mickael here: > >>>>> https://www.eclipse.org/lists/orbit-dev/msg05509.html > >>>>> > >>>>> -Gunnar > >>>>> _______________________________________________ > >>>>> orbit-dev mailing list > >>>>> orbit-...@eclipse.org > >>>>> To unsubscribe from this list, visit > >>>>> https://www.eclipse.org/mailman/listinfo/orbit-dev > >>>>> > >>>>> _______________________________________________ > >>>>> cross-project-issues-dev mailing list > >>>>> cross-project-issues-dev@eclipse.org > >>>>> 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@eclipse.org > >>>> To unsubscribe from this list, visithttps:// > www.eclipse.org/mailman/listinfo/cross-project-issues-dev > >>> > >>> _______________________________________________ > >>> cross-project-issues-dev mailing list > >>> cross-project-issues-dev@eclipse.org > >>> To unsubscribe from this list, visithttps:// > www.eclipse.org/mailman/listinfo/cross-project-issues-dev > >> > >> > >> _______________________________________________ > >> cross-project-issues-dev mailing list > >> cross-project-issues-dev@eclipse.org > >> To unsubscribe from this list, visithttps:// > www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > cross-project-issues-dev@eclipse.org > > 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@eclipse.org > 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@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
