[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] [orbit-dev] log4j vulnerability in Eclipse?
|
Could someone add note which *IDE packages* built by eclipse.org include affected log4j2 and which versions of those packages are vulnerable?
Am 13. Dezember 2021 22:45:35 MEZ schrieb Denis Roy <denis.roy@xxxxxxxxxxxxxxxxxxxxxx>:
>I am going to crowd-source this. I need everyone to chime in on this
>Wiki page:
>
>https://wiki.eclipse.org/Eclipse_and_log4j2_vulnerability_(CVE-2021-44228)
>
>
>I will see that this information gets broadcast tomorrow, once there is
>some information in the table.
>
>
>Denis
>
>
>On 2021-12-13 15:03, Jonah Graham wrote:
>> 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 <http://www.kichwacoders.com>
>>
>>
>> On Mon, 13 Dec 2021 at 14:50, Denis Roy
>> <denis.roy@xxxxxxxxxxxxxxxxxxxxxx> 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 <http://www.kichwacoders.com>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 13 Dec 2021 at 13:58, Denis Roy
>>>>>>> <denis.roy@xxxxxxxxxxxxxxxxxxxxxx> 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 <http://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 <http://www.kichwacoders.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, 13 Dec 2021 at 12:58, Ed Merks
>>>>>>>> <ed.merks@xxxxxxxxx> 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
>>>>>>>> >>>>>>> gunnar@xxxxxxxxxxxxxxx, http://guw.io/
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>> On Dec 11, 2021, at 20:36, Matthias Sohn
>>>>>>>> >>>>>>>> <matthias.sohn@xxxxxxxxx> wrote:
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> On Sat, Dec 11, 2021 at 11:35 AM Gunnar
>>>>>>>> Wagenknecht
>>>>>>>> >>>>>>>> <gunnar@xxxxxxxxxxxxxxx> wrote:
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> Alexander,
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>>> On Dec 11, 2021, at 10:16, Alexander
>>>>>>>> Fedorov
>>>>>>>> >>>>>>>>> <alexander.fedorov@xxxxxxxxxx> 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@xxxxxxxxxxx
>> 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@xxxxxxxxxxx
>> To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Kind regards,
Andrey Loskutov
https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих
