On Thu, Jan 13, 2022 at 11:52 AM Christoph Läubrich <lae...@laeubi-soft.de> wrote:
> 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.fedo...@arsysop.ru>: > >>>>>>>> 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@eclipse.org > >>>>>>>>> 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@eclipse.org > >>>>>> 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@eclipse.org > >>>>> 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@eclipse.org > >>>> 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@eclipse.org > >>> 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@eclipse.org > >> 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@eclipse.org > > 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@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > -- Aleksandar Kurtakov Red Hat Eclipse Team
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
