log4j2 version 2.16.0 just showed up on maven central a few moments ago. https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.16.0/ https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.16.0/
- Joakim On Mon, Dec 13, 2021 at 2:06 PM Matthias Sohn <matthias.s...@gmail.com> wrote: > I think there is some confusion since naming of log4j 1 and 2 artefacts is > a bit confusing: > > *log4j 1.x* > > maven artefact log4j: > log4j:log4j:1.2.17 > > bundle in Orbit log4j > org.apache.log4j 1.2.15.v201012070815 > > slf4j log4j 1 binding to use log4j 1.x with libraries using slf4j api: > org.slf4j:slf4j-log4j12:1.7.32 > > *log4j 2.x* > > maven artefact log4j 2.x: > org.apache.logging.log4j:log4j-api:2.15.0 > org.apache.logging.log4j:log4j-core:2.15.0 > > bundle in Orbit log4j 2.x: org.apache.logging.log4j 2.15.0.v20211211-1928 > (contains classes from both log4j-core and log4j-api) > > slf4j log4j 2 binding to use log4j with libraries using slf4j api: > org.apache.logging.log4j:log4j-slf4j-impl:2.15.0 > > > > On Mon, Dec 13, 2021 at 8:33 PM Denis Roy < > denis....@eclipse-foundation.org> wrote: > >> The CVE shows: Apache Log4j2 >> >> I would assume that is correct. >> >> >> On 2021-12-13 14:31, Ed Willink wrote: >> >> Hi >> >> Please start by correctly referencing the vulnerability. >> >> It is with org.apache.logging.log4j, >> >> There is no issue with org.apache.log4j so continually referring to this >> as a log4j vulnerability is very misleading. >> >> AFAICT no Eclipse installation of mine has ever included >> org.apache.logging.log4j. >> >> Regards >> >> Ed Willink >> On 13/12/2021 19:15, Denis Roy wrote: >> >> How about I start: >> >> >> title: *Eclipse and log4j vulnerability **(CVE-2021-442280)* >> >> Here is the status of the various Eclipse Foundation projects, with >> regards to CVE-2021-442280: >> >> >> - Eclipse IDE 2021-12: *not vulnerable* >> >> - Eclipse Jetty (version): status >> >> - Eclipse GlassFish (version): status >> >> - Eclipse jGit (version): status >> >> >> We would likely need to get the input from other projects, to >> "self-certify". I can do this by reaching out to eclipse.org-committers if >> anyone agrees. >> >> At this point, most of Europe is logged out for the day, and time is >> ticking away fast for this sort of action. >> >> >> Denis >> >> >> >> >> >> On 2021-12-13 14:00, Jonah Graham wrote: >> >> 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 listcross-project-issues-...@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> -- >> >> *Denis Roy* >> >> *Director, IT Services | **Eclipse Foundation* >> >> *Eclipse Foundation* <http://www.eclipse.org/>*: The Community for Open >> Innovation and Collaboration* >> >> Twitter: @droy_eclipse >> >> _______________________________________________ >> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> Virus-free. >> www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> <#m_188903747482311703_m_-5599836476997852677_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> _______________________________________________ >> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> -- >> >> *Denis Roy* >> >> *Director, IT Services | **Eclipse Foundation* >> >> *Eclipse Foundation* <http://www.eclipse.org/>*: The Community for Open >> Innovation and Collaboration* >> >> Twitter: @droy_eclipse >> _______________________________________________ >> 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
