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