Hi Christoph,
That sounds reasonable to me and an interesting solution. Could SimRel
include it as a sub/composite repo? Would adding it to the released
composite repos cause the Check for Updates to remove (prompt to remove)
the problematic jars?
Is that a p2 site you can craft for this issue? My p2 knowledge isn't
sufficient for such a task.
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com <http://www.kichwacoders.com>
On Mon, 13 Dec 2021 at 11:30, Christoph Läubrich <laeubi@xxxxxxxxxxxxxx
<mailto:laeubi@xxxxxxxxxxxxxx>> 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.
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).
What will happen then is that P2 will give the user the choice to
install this mitigation unit and uninstall
a) the dangerous bundle
b) any dependent and affected unit (passage in this case)
from the current IDE.
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.
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.
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.
What do you think does this sounds reasonable?
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>
>>>>>
>>>>> -Gunnar
>>>>> _______________________________________________
>>>>> orbit-dev mailing list
>>>>> orbit-dev@xxxxxxxxxxx <mailto:orbit-dev@xxxxxxxxxxx>
>>>>> To unsubscribe from this list, visit
>>>>> https://www.eclipse.org/mailman/listinfo/orbit-dev
<https://www.eclipse.org/mailman/listinfo/orbit-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>
>>>>
>>>>
>>>> _______________________________________________
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>>> To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
<http://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,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
<http://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,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
<http://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>
>
_______________________________________________
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
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
