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