Hi Denis, Yes - that seems best. I can help with the actual story - as can others on this list (I hope :-).
Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Mon, 13 Dec 2021 at 13:58, Denis Roy <denis....@eclipse-foundation.org> wrote: > Good question. > > If we agree on a story (ie, if someone can help me write what the actual > story is), I can certainly post a blog post on the blogs.eclipse.org > domain. From there, we could tweet about it from the official @EclipseFdn > twitter account, and perhaps add links to the post from the Newcomers forum. > > Does that seem acceptable? > > > Denis > > > > > > On 2021-12-13 13:44, Jonah Graham wrote: > > 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 >> >>>>>>>> > > > _______________________________________________ > 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
