We had a fairly productive meeting on Wednesday with
regards to the future of the Jarsigning requirement.
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:
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:
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
~~~