Hi
folks,
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
~~~