Denis, It is the log4j vulnerability, the fact that it doesn't affect some versions of log4j is in the vulnerability description. Please continue doing this - I appreciate it.
Most media reports call it simply log4j - but you can reduce the noise by calling it "Eclipse and log4j2 vulnerability (CVE-2021-44228)" Ed, I am delighted that we are dependent on a version of log4j that doesn't have this problem - but I wouldn't get too excited about promoting that Eclipse IDE hasn't updated a dependency. log4j 1.2 has been EOL for 6+ years (https://logging.apache.org/log4j/1.2/). I am glad this vulnerability doesn't exist, but log4j 1.2 does have its own problems - like CVE-2019-17571 - so nothing to get too excited about. Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Mon, 13 Dec 2021 at 14:50, Denis Roy <denis....@eclipse-foundation.org> wrote: > IANAD so perhaps I'm the worst possible person to be doing this. > > > > On 2021-12-13 14:47, Ed Willink wrote: > > Hi > > Maybe the CVE is also misleading or the discussion here is very wrong. The > current Orbit repo contains > > org.apache.log4j 1.2.15 is clearly not log4j2. It has been in use > unchanged in every Eclipse distribution for at least the last ten years. > > The analysis on this thread has been about org.apache.logging.log4j which > could be a log4j2. It is unused in core and many Eclipse configurations. > > Please be precise. > > Regards > > Ed Willink > > On 13/12/2021 19:33, Denis Roy 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 list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
