Thanks everyone for working on this - I think we have a pretty good story now about what the Eclipse IDE / SimRel has done for the log4j vulnerability.
The last thing is to say so in a concise way - where can/should we say so (besides this mailing list)? Thanks, Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Mon, 13 Dec 2021 at 12:58, Ed Merks <ed.me...@gmail.com> wrote: > Christoph, > > I really appreciate your creative ideas. I think "we, i.e., as an I" > should indeed plan long term for the possibility of expedient mitigation > of such problems in the future using this type of approach. > > For the project catalogs I've regenerated them such than installing any > version of the RCP package (with any installer) will install the latest > version of Passage which strictly requires the updated/fix version of > org.apache.logging.log4j. Also any installer-created RCP package > installation will ask to update itself upon startup/restart. > > > https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=929d140afc34ecdb85b7996c63ce0b36b6723a34 > > Another thought I had is that the donation support I've added opens a > browser page. In this case we could change the URL such that a page > with information about this CVE could be presented... > > But now it's late in the day and I'm done for now. > > Regards, > Ed > > On 13.12.2021 18:03, Christoph Läubrich wrote: > > Hi Ed, > > > > > One problem is we don't know all the things that strictly require the > > > older bundle. > > > > In the end what matters is that the bundle is no longer available. If > > we don't uninstall them at laes they won't resolve anymore and people > > will go to the project website, report an issue and/or install an > > update :-) > > > > > In the end it at the simplest, it could just be a feature with p2.inf > > > with negative requirements for bundles that have been determined to be > > > unsafe. > > > > yep that's what I have had in mind, I think it would be cool to have > > one global feature "CVE Mitigation" or something and this > > requires/includes individual CVE features that ship with appropriate > > p2.inf items. > > Thus way, once added to an IDE this will enable us to make CVE fixes > > available tor a broad audience and make people more aware of them > > through the update capabilities of eclipse itself. > > > > >> What do you think does this sounds reasonable? > > > It's a creative idea. I like it. > > > > Good to hear! As you probably know much more about p2.inf magic than > > me can you craft such a feature so we can investigate this more? As > > mentioned before this is more an idea so I can't shar any concrete > > code samples yet and have no idea where this would bes be placed (part > > of the platform cbi? github/gitlab project under eclipse umbrella? > > eclipse cbi maybe?) > > > > > > Am 13.12.21 um 17:48 schrieb Ed Merks: > >> Christoph, > >> > >> Comments below. > >> > >> On 13.12.2021 17:29, Christoph Läubrich 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. > >> Of course not everyone has Passage installed, nor this specific > >> bundle... > >>> > >>> 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). > >> Yes that's theoretically possible. (And in the catalog I can easily > >> do this, but not all installation are installed from the catalog.) > >>> > >>> What will happen then is that P2 will give the user the choice to > >>> install this mitigation unit and uninstall > >> P2 generally wants to install features so such a thing would need to > >> be packaged up as a feature... > >>> > >>> a) the dangerous bundle > >>> b) any dependent and affected unit (passage in this case) > >>> > >>> from the current IDE. > >> One problem is we don't know all the things that strictly require the > >> older bundle. The parts of Passage contributed to the train only > >> have lower bounds, but there are Passage features that include this > >> bundle with an exact range... > >>> > >>> 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. > >>> > >> Another question is what else out there that might already be > >> installed depend on logging.log4j and would also need to be updated > >> or uninstalled? That's an open ended question... > >>> 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. > >>> > >> Yes, such a thing will follow some pattern so generating such a thing > >> would be good... > >>> 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. > >> In the end it at the simplest, it could just be a feature with p2.inf > >> with negative requirements for bundles that have been determined to > >> be unsafe. > >>> What do you think does this sounds reasonable? > >> It's a creative idea. I like it. > >>> 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 > > _______________________________________________ > > 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
