Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Future of Jarsigning requirement

Hi folks,

Based on the current votes/comments I have sent our request (#3) to the steering committee with a link to Mickael's document[1]. If you haven't seen the document it still leaves us in a little bit of a catch-22 as presented, but I don't think that catch-22 needs to exist. The question that the IDE WG Steering Committee needs to answer is whether the technical implementation in the Eclipse Platform meets security considerations.

(FWIW I see this as equivalent to Eclipse Platform allowing installing unsigned content, but SimRel does not allow that. Or seen another way, it is pretty hard for SimRel to require something that the Eclipse Project does not implement!)

[1] https://docs.google.com/document/d/1dl10ia092X5hN1qfKoHYvriCNM-iBqiOkfjnntxaBbk/edit?usp=sharing
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 13 Oct 2021 at 14:33, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Hi folks,

We had a fairly productive meeting on Wednesday with regards to the future of the Jarsigning requirement.

The current signing requirement is defined as follows in the simrel requirements:

Signing (tested)

Projects must use signed plugins and features using the Eclipse certificate.

[added 12/2015, for Neon]. Note: If a jar is already signed by the Eclipse certificate, then it must not be re-signed by projects for the release train.


And the handbook says:

Signed Artifacts

Where technically sensible, all downloadable artifacts should be signed by an Eclipse Foundation certificate.


Proposal

This is the proposed replacement for SimRel

Signing

Projects must deliver signed plugins and features to the Eclipse SimRel repository. These can be jarsigned with the Eclipse certificate, or they can be signed using a PGP key in the web of trust of the Eclipse Foundation key with the signature stored in the p2 metadata. The Eclipse Webmaster issues per-project keys which are suitable for such use.

It is permissible to sign with both methods, see the wiki entry on Jar Signing to ensure that the multiple signatures are handled correctly or for any other information on how to perform the signing.

The signing of artifacts delivered by SimRel is an important piece to achieve the overall goal of "Build artifacts made available at the Eclipse Foundation are verifiably the ones built by respective projects." The signing allows users to either as part of the installation, or at a later time, to verify that the downloaded artifacts are the ones that various projects have published. See the wiki entry on Jar Signing for information on how to perform such verification.

The Eclipse Platform (Equinox's p2 specifically) will verify, using checksums, that downloaded artifacts match the checksums in the metadata. Users can optionally enable various levels of signature verification as made available by the Eclipse Platform (Equinox's p2 specifically).


Assuming the above is acceptable for SimRel, then the Eclipse Handbook could be updated to read as follows:

Signed Artifacts

Where technically sensible, all downloadable artifacts should be signed by an Eclipse Foundation certificate or a PGP key that is in the Eclipse Foundation's web of trust.


What Next?

There are a number of items left to resolve:

1) The Planning Council must approve the changes to SimRel requirements. Please reply +1 to indicate your approval.

2) The Planning Council will recommend to the Eclipse Foundation the changes to the handbook. Please reply +1 to indicate your approval of this recommendation to the Eclipse Foundation.

3) The Planning Council will recommend to the Steering Committee that an audit of the security practices of the SimRel be conducted. Please reply +1 to indicate your approval of this recommendation to the steering committee.

4) The Eclipse Platform team has indicated their intention to do some additional usability improvements. The summary is that the current implementation of PGP signing in Eclipse Platform causes security prompts to confirm users trust the content (IIUC similar to how self signed jars are presented). Please reply +1 to indicate your approval with having an initial release with these prompts. 


Therefore, can all planning council members reply with +1 for each of the four items. I think the first three above are fairly straightforward. If you don't think the third item is ok as is, please indicate what you believe the minimal viable implementation looks like? 


Thanks,
Jonah




~~~

Jonah Graham
Kichwa Coders
www.kichwacoders.com

Back to the top