The stated changelog for log4j2 version 2.16.0 is ... * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be set to true to allow JNDI. * LOG4J2-3211: Completely remove support for Message Lookups.
Changelog from the mailing list - https://lists.apache.org/thread/6g0ls1cc9htn52hr0kkbo7dds5ts3rb5 - Joakim On Mon, Dec 13, 2021 at 2:44 PM Joakim Erdfelt <joakim.erdf...@gmail.com> wrote: > 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_-3328732685233212968_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
