Skip to main content

[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?

This weaving capability looks much more promising for attacker than JNDI from the initial topic.

Regards,
AF

12/15/2021 12:22 PM, Christoph Läubrich пишет:
And if you still think it is a good idea to patch *classes* you can do so using the "Weaving Hook Service Specification" [1].

With that you can replace the content of *any* class with something else (patched, throwing an exception, dynamic code replacement using javassist...).

[1] http://docs.osgi.org/specification/osgi.core/7.0.0/framework.weavinghooks.html

Am 15.12.21 um 06:33 schrieb Ed Merks:
Ed,

I too thought maybe that would be possible via a fragment, but the bundle's classpath contributions come before each of its fragments classpath contributions so the bundle would have to be designed to allow a fragment to contribute something that would be processed before its own classes:

https://wiki.eclipse.org/FAQ_Can_fragments_be_used_to_patch_a_plug-in%3F

Regards,
Ed

On 14.12.2021 21:04, Ed Willink wrote:

Hi

Rather than remove and so change the existing log4j1 Orbit content, might it be easier to outwit the lazy load, by ensuring the the platform/p2 eagerly provides a spoof implementation of the unwanted class?

    Regards

        Ed Willink

On 14/12/2021 12:00, Jeanne, Federico wrote:

Ed,

thank you for the detailed analysis. I guess you’re right: determining the real exposure of each one of the plugins and features when it comes to such a central component like Log4J is really challenging.

The good thing though is that, like you already showed, the risk seems to be contained into only in 1 package (org.apache.log4j.net) and only a bunch of plugins seem to include a (non-greedy) dependency to that package. I like the idea of removing that package from future version of “org.apache.log4j” but I have to admin I can’t really assess what that actually means in terms of effort and consequences.

Anyway, I just wanted to use the momentum to try and dig a bit deeper and to preemptively search for similar issues that might arise in the future :)

Regards,

Federico

*From:*cross-project-issues-dev <cross-project-issues-dev-bounces@xxxxxxxxxxx> *On Behalf Of *Ed Merks
*Sent:* Tuesday, December 14, 2021 10:36 AM
*To:* cross-project-issues-dev@xxxxxxxxxxx
*Subject:* Re: [cross-project-issues-dev] [orbit-dev] log4j vulnerability in Eclipse?

Jeane,

The following is not saying your suggestion is a bad idea, but rather to clarify the nature of what we will need to say and do...

Eliminating the use of org.apache.log4j quickly seems unpromising at best.

At least superficially we might as well list all projects as affected.

Just looking at the first two dependencies:

And then following the dependencies of second of those:

We see that pretty close to the entire universe of Eclipse plugins is downstream from these.

And then, we don't know for a fact that anyone actually creates an org.apache.log4j.net.SocketServer...

Looking more closely at the nature of the dependencies though, it appears that org.apache.commons.logging only depends on the org.apache.log4j package:

And then it's only an optional, non-greedy dependency:

Nothing (on the release train) depends on the org.apache.log4j.net package where the offending class is located:

In the end, determining whether there is an actual risk rather than a hypothetical risk challenging at best.  I expect that everyone (and I do mean literally everyone using this bundle) is just doing this and has zero risk:

  private static final Logger log = Logger.getLogger(<SomeClass>class);

Perhaps we could create a new version of org.apache.log4j that removes the org.apache.log4j.net.SocketServer class (or the entire package), as a crude quick fix, but even that would require some IUs to relax/modify their bounds:

This site suggests there is a 1.2.18 version of log4j though elsewhere it I saw a statement that the problem would not be fixed.

https://www.whitesourcesoftware.com/vulnerability-database/CVE-2019-17571

Accurate information is hard to come by...

Regards,
Ed

On 14.12.2021 09:42, Jeanne, Federico wrote:

    Denis,

    good idea with the page, I think it brings a nice overview of
    what has been investigated and how deep the vulnerability reached.

    I couldn’t help noticing though that some of the listed projects
    mentioned using Log4j 1.2.15. Wouldn’t it also make sense to have
    another page to address the vulnerability CVE-2019-17571 (the one
    Jonah mentioned)?

    Regards,

    Federico

    *From:*cross-project-issues-dev
    <cross-project-issues-dev-bounces@xxxxxxxxxxx>
<mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx> *On Behalf
    Of *Denis Roy
    *Sent:* Monday, December 13, 2021 10:46 PM
    *To:* cross-project-issues-dev@xxxxxxxxxxx
    *Subject:* Re: [cross-project-issues-dev] [orbit-dev] log4j
    vulnerability in Eclipse?

    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)
<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/
        <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
        <mailto: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
<mailto: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
<mailto: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
<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
<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
<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
<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
<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
<https://www.eclipse.org/lists/eclipse.org-committers/msg01333.html>
>>>>>>>
>>>>>>> -Gunnar
>>>>>>>
>>>>>>> -- >>>>>>> Gunnar Wagenknecht
>>>>>>> gunnar@xxxxxxxxxxxxxxx
<mailto:gunnar@xxxxxxxxxxxxxxx>,
                                            http://guw.io/
<http://guw.io/>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 11, 2021, at 20:36, Matthias Sohn
>>>>>>>> <matthias.sohn@xxxxxxxxx
<mailto:matthias.sohn@xxxxxxxxx>>
                                            wrote:
>>>>>>>>
>>>>>>>> On Sat, Dec 11, 2021 at 11:35 AM Gunnar Wagenknecht
>>>>>>>> <gunnar@xxxxxxxxxxxxxxx
<mailto:gunnar@xxxxxxxxxxxxxxx>>
                                            wrote:
>>>>>>>>
>>>>>>>>     Alexander,
>>>>>>>>
>>>>>>>>>     On Dec 11, 2021, at 10:16, Alexander Fedorov
>>>>>>>>> <alexander.fedorov@xxxxxxxxxx
<mailto: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
<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
<https://www.eclipse.org/lists/orbit-dev/msg05509.html>
>>>>>>>>

            _______________________________________________
            cross-project-issues-dev mailing list
            cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
            To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
<https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>




        _______________________________________________

        cross-project-issues-dev mailing list

        cross-project-issues-dev@xxxxxxxxxxx <mailto:cross-project-issues-dev@xxxxxxxxxxx>

        To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev <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@xxxxxxxxxxx

    To unsubscribe from this list, visithttps://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

<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>

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

_______________________________________________
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

_______________________________________________
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, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



Back to the top