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
~~~