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,
