| Hi Carl,
I believe this is a non-issue for a couple of reasons. We do trust the community to do the right thing. We do have a couple of checks in place to detect this, though.
The way Orbit with EBR works, the malicious library must make it into Maven Central first. I think there will be many more eyes watching this than just Orbit committers. Also, the process for getting an update to an existing library into Maven Central requires some proof already that the update is coming from the project team. To my memory, the case you cited happened outside the Maven/Java community. I see it much more difficult to achieve that in the Maven world.
Additionally, adding an updated version to Orbit does not automatically trigger a project using it. It still needs another contribution to the project. Thus, the project team will be aware and can do their own vetting before consuming the library.
Last but not least, we still have our IP process in place. This ensures license vetting. It will not do content based reviews, though. But it will bring new possibilities around automation. Thus, I'm expecting the upcoming IP tooling to help in detecting problems quicker than before.
-Gunnar
Folks,
This actually concerns me. My biggest concern is a malicious update- there has already been one instance where someone took over maintenance of an existing open source library and added in hooks where the library could be exploited. What would stop anyone from saying "I have a new version of X", contributing it to Orbit, and it is X plus virus/worm/backdoor? I would much rather have the onus upon an Eclipse project/team that must vet the software before it goes into Orbit. This becomes even worse if Eclipse signs the Orbit bundles, since the people involved could then take the signed contents and redistribute it outside of Eclipse (and thus bypass checks for signed software).
I know that there are people willing to help, and I would love to do whatever possible to help those people. I also know that there are people willing to exploit. The question is, what checks and balances will be in place to let the first group through, but keep the damage from the second group to a minimum?
But then again, maybe this is just me?
FWIW,
- Carl Anderson
WTP PMC member
<graycol.gif>Jonah Graham ---10/23/2019 09:16:51 AM---+1 - if there are people willing to help we should do what we can to make it possible.
From: Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
To: Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
Date: 10/23/2019 09:16 AM
Subject: [EXTERNAL] Re: [orbit-dev] Evolving Orbit's Process/Policy
Sent by: orbit-dev-bounces@xxxxxxxxxxx
+1 - if there are people willing to help we should do what we can to make it possible. ~~~ Jonah Graham Kichwa Coders
www.kichwacoders.comOn Wed, 23 Oct 2019 at 09:11, Gunnar Wagenknecht < gunnar@xxxxxxxxxxxxxxx> wrote:
All,
I had a chat at EclipseCon today with a user/consumer of Eclipse. They are concerned about some outdated libraries that Eclipse ships. They are interested in contributing updated to the library. In the past they reported difficulties with such contributions. I recall we always expect contributions coming from another project not from the outside.
I'd like to propose that we open Orbit for these kind of contributions. It should be possible for anyone to just submit a recipe for an updated version of a library. This accelerates the process IMO. We should stop asking "which project is this request coming from" and just be happy that someone is helping us reducing Orbit's technical debt.
To clarify, I'm not suggesting to accept contributions for *any* library - *only* updates to existing libraries.
Thoughts?
FWIW, expect CQs to be no longer an issue in this discussion. We (the Orbit committers) will create one in the beginning, when accepting such a contribution. They are going away eventually (yeah!).
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/orbit-dev_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/orbit-dev
_______________________________________________ orbit-dev mailing list orbit-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orbit-dev
|
