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