Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-ide-wg] jarsigning vs jetty (and others)

Hi Mickael,

The minutes will be published soon (next week?) - but in the meantime you can glean what is happening from https://www.eclipse.org/lists/eclipse.org-planning-council/msg03438.html specially:

- Jar signing : The WG intent about that is "Build artifacts made available at the Eclipse Foundation are verifiably the ones built by respective projects."
- Explains the role and responsibilities of the WG steering committee vs planning council

Jonah



~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Thu, 2 Sept 2021 at 16:42, Mickael Istria <mistria@xxxxxxxxxx> wrote:
Hello,

Was this discussed in last meeting? What's the working group opinion on this issue?

Cheers,

On Thu, Aug 19, 2021 at 9:45 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
> what are the actual security issues that we want to see prevented for the Eclipse IDE? What are the requirements, and who is really backing up these requirements? 

+1 that is the exact questions we need to answer. The agenda for steering committee meeting Tuesday has a good chunk of time dedicated to this now, in addition to the discussions already started. 

Jonah 


On Thu., Aug. 19, 2021, 14:36 Mickael Istria, <mistria@xxxxxxxxxx> wrote:


On Thu, Aug 19, 2021 at 6:37 PM Ed Merks <ed.merks@xxxxxxxxx> wrote:

Discussions at the Steering Committedd are underway.  The committee meets next Tuesday where we will get a chance to discuss the issue virtually face-to-face...

Good, thanks.

Could I ask a favor that you outline (briefly summarize) the specifics of your PGP proposal?


I'll do it just after, but I'd like to suggest that discussion first focuses on the actual issue of Jetty or other 3rd party libs that are expansive to adopt because of requirement for jarsigner through Orbit as example to support a decision, and then evaluation of potential solutions should happen the other way round: independently of the technology (jarsigner, PGP or whatever or even nothing), what are the actual security issues that we want to see prevented for the Eclipse IDE? What are the requirements, and who is really backing up these requirements? A comparative approach with other platforms would also be interesting.
Some specific questions can be: do we need the user to decide whether to trust an artifact or not? Do we need some automated decision? Do we need something stamped by Eclipse Foundation before it participates in SimRel?... Having clear requirements will allow to identify what can be a good solution. Probably, we'll also realize that the expressed requirements seem unreasonable for sustainability and innovation and will first have to start debating them and balance the value/cost to pick a good subset.

Currently we start playing with PGP in p2 and Tycho because it's the industry standard and many of us involved in these projects do believe it's a technology worth pursuing, for Eclipse projects but also for external extensions. We have hope it can be good enough for SimRel (like it's good enough for some other platforms & communities), but we cannot yet claim it's a good enough replacement as long as we don't have clear requirements.

In the current state, we have p2 verifying at install-time whether an artifact matches PGP signatures that are part of p2 metadata, and fail installation if signature and artifact don't match (ie "artifact was tampered after signature"). With this, we can then ask user whether they trust at least 1 signer of the artifact: just like with jarsigner, the point is to delegate the "I trust this artifact" decision to "I trust this signer". If a signer is trusted, then install proceeds otherwise it's aborted.
There are some important differences in PGP compared to jarsigner (no centralized trust store or trust chain but keyservers, keys can be revoked, it's easy to build a key pretending to be someone else) and the model of trust also differs: it's a "web of trust" with multiple paths of trust (A trusts X trusts C; or A trusts Y trusts C), but that approach assume we transitive trust, and there are some popular keyservers available that take care of verifying a key actually match the declared author or whether it is revoked. Those are more hints for users in taking the decision whether to trust or not; the "web of trust" model isn't really meant to automate trust decision.
Some other questions arise if we want to think about PGP & SimRel particularly: 3rd party artifacts are usually already PGP-signed (Nexus so most Maven repositories mandate it in order to publish). So in Eclipse world, who should sign the artifacts -there can be multiple signers-. And would we want to automatically trust some keys?

A lot of food for thought...
Cheers,
_______________________________________________
eclipse-ide-wg mailing list
eclipse-ide-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-ide-wg
_______________________________________________
eclipse-ide-wg mailing list
eclipse-ide-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-ide-wg


--
Mickael Istria
Eclipse IDE developer, for Red Hat Developers
_______________________________________________
eclipse-ide-wg mailing list
eclipse-ide-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-ide-wg

Back to the top