Hi Alexander,
I think no one should depend on passage providing the dependency for
them, I just suggested this as it seems passage is the only consumer of
that orbit bundle in simrel (as m2e is for bnd-lib).
About the trust-orbit one must really ask what that should mean.
Actually Orbit was just a source of IP reviewed items and adding some
OSGi meta-data in some cases.
I can't remember that any security-audit was ever done before
including/updating something in orbit, but I probably just missed
something. And even if, it obviously has missed the CVEs discovered now
so one could really ask if Orbit puts that much extra trust given that
often items are long time outdated and missing security updates/fixes.
IMHO, people should actively remove content from Orbit that has CVEs. Much like with any other project. Even without replacing it with a fixed version. We will be better with less but trusted content than questioning ourselves for each artifact.
Am 13.01.22 um 10:42 schrieb Alexander Fedorov:
> Thank you, Ed
>
> You are definitely right, the notice from my side was very late, sorry
> for not discovering this Orbit contribution problem earlier.
> Since Jonah updated the orbit.aggrcon before the staging we should have
> the log4j 2.15.0 in the SimRel. The log4j 2.15.0 is not the latest one
> but has a fix for the most famous vulnerability.
>
> Thank you, Christoph
>
> I'll definitely try the suggested approach to weaker the dependency to
> Orbit.
>
> However, that means that dependency form Orbit has became a toxic one,
> since the focus of attention through all the discussion is always on
> consuming component (Passage in our case) rather than on the root cause
> (Orbit). Here we can observe the transfer of responsibility for Orbit
> content to the downstream component that was unlucky enough to
> contribute the bundle from Orbit to SimRel. That is definitely something
> new, since Orbit was a trusted source of 3rd party libraries for many
> years.
>
> Regards,
> AF
>
> 1/13/2022 11:53 AM, Ed Merks пишет:
>> Christoph,
>>
>> That's cool. Thanks for sharing. :-)
>>
>> Regards,
>> Ed
>>
>>
>> On 13.01.2022 09:49, Christoph Läubrich wrote:
>>> Hi Ed,
>>>
>>>> If that implies PGP signed content on the train
>>>
>>> Nope, this will (res)sign the artifact with standard eclipse-jar signer.
>>>
>>> m2e uses this approach to contribute bnd-lib to simrel what is from
>>> p2 but without signature, the same works for artifacts of any source....
>>>
>>>> BTW, when one chooses to do this "direct from Maven" thing, can one
>>>> also choose to create the source bundle/attachment for it?
>>>> It will be super annoying in the future to have a growing bunch of
>>>> black-box libraries without associated sources...
>>>
>>> m2e+tycho support automatic source-bundle generation of associated
>>> source for maven items (see for example this screenshot[1]) when
>>> "Include Artifact Sources" is enabled.
>>>
>>> [1]
>>> https://user-images.githubusercontent.com/1331477/139412713-e0218ff7-642c-4c19-afac-55fca49ef325.png
>>>
>>>
>>> Am 13.01.22 um 09:42 schrieb Ed Merks:
>>>> Christoph,
>>>>
>>>> If that implies PGP signed content on the train, then no, Eclipse
>>>> Passage should not choose to do that at this time because PGP
>>>> support is not yet ready for prime time, but we are working on that;
>>>>
>>>> https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg.eclipse.org/-/issues/11
>>>>
>>>>
>>>> BTW, when one chooses to do this "direct from Maven" thing, can one
>>>> also choose to create the source bundle/attachment for it? It will
>>>> be super annoying in the future to have a growing bunch of black-box
>>>> libraries without associated sources...
>>>>
>>>> Regards,
>>>> Ed
>>>>
>>>> On 13.01.2022 09:37, Christoph Läubrich wrote:
>>>>> Eclipse Passage might choose to consume the log4j2 directly from
>>>>> maven and simply sign the artifact to comply with simrel rules as
>>>>> done here:
>>>>>
>>>>> https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.site/pom.xml#L45
>>>>>
>>>>>
>>>>> This would bypass the
>>>>> OrbitChange>OrbitRelease>PassageChange>PassageRelease>RepeatHere
>>>>> cycle...
>>>>>
>>>>> Am 13.01.22 um 09:31 schrieb Alexander Fedorov:
>>>>>> Hello,
>>>>>>
>>>>>> Some hours ago I've found that Orbit still contributes the log4j
>>>>>> vulnerability to the SimRel
>>>>>>
>>>>>> Thanks to Jonah, the situation is better, now we have updated
>>>>>> Orbit with log4j 2.15.0
>>>>>>
>>>>>> But shouldn't we hold a train a bit to use the latest fix from
>>>>>> Orbit that provides log4j 2.17.1?
>>>>>>
>>>>>> Regards,
>>>>>> AF
>>>>>>
>>>>>> 12/18/2021 4:19 PM, Andrey Loskutov пишет:
>>>>>>> After update is before update...
>>>>>>>
>>>>>>> log4j has now 2.17.0.
>>>>>>> https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
>>>>>>>
>>>>>>>
>>>>>>> Am 15. Dezember 2021 12:03:21 MEZ schrieb Alexander Fedorov
>>>>>>> <alexander.fedorov@xxxxxxxxxx>:
>>>>>>>> Thank you, Andrey!
>>>>>>>>
>>>>>>>> Just merged
>>>>>>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188862
>>>>>>>> Will be working to provide Eclipse Passage 2.2.2 service release.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> AF
>>>>>>>>
>>>>>>>> 12/15/2021 1:38 PM, Andrey Loskutov пишет:
>>>>>>>>> +1 from me.
>>>>>>>>> The hype is too big.
>>>>>>>>>
>>>>>>>>> Re-posting your message to collect more feedback regarding:
>>>>>>>>> should we replace 2.15.0 with 2.16.0 in Orbit?
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>> Спасение утопающих - дело рук самих утопающих
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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
_______________________________________________
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
