Comments below.
On 19.01.2021 11:22, Mickael Istria wrote:
Hi all,
With recent improvements in Tycho and PDE to easily consume external
artifacts from Maven Central or other Maven repo and additions in m2e
to include BND bundles, a new issue has emerged: SimRel currently
mandates that contributed artifacts are signed with the Eclipse
Foundation certificates and jarsigner.
The EDP, not just SimRel, mandates this:
https://www.eclipse.org/projects/handbook/#resources-signing
While this is easy for pure Eclipse bundle, it's trickier for
"imported" artifacts as signing them means we alter the artifacts, so
they're not the upstream artifacts any more, so Bundle-Vendor and
artifactId have to be changed and so on, leading to quite some
difficulties and risk of collisions of official vs altered bundles.
Although it's not confirmed yet, the important reason why SimRel
mandates signing is that it is expected that the warning popup shows
up for unsigned content, to inform users about potential unsecure content.
Signing is a certification of origin that follows the artifact around no
matter where it goes...
We're brainstorming about other approaches to signing bundles, that
would not involve modifying the artifact in order to sign it.
What Maven Central current mandates is that the artifacts are signed
(using PGP) and that signature files are pushed together with the
artifact. The signatures are verified when pushing to the Central
repository, and -on demand- by people who download content from this
repository. The repository hosts the signing info and doesn't put that
inside the artifact file. I think it would be a good fit for our
current needs in the Eclipse ecosystem.
As I currently imagine, p2 could host the signature information for
artifacts in its metadata. And at installation, p2 would verify the
signatures similarly to how it verifies checksums and would make
installation fail is artifact isn't the one that was signed in the
metadata.
I think before we talk about a technical solution we should validate the
assumption that consumers don't actually care about signing and that the
Foundation is okay with changing the rules about it. I say that
because a p2 solution that is just an install-time solution, like a
fancy checksum, rather than a run time solution, has implications for
consumers.
This signature informations could ideally handle different signature
verifications. For example it could be a property on an artifact
`sign=Eclipse Foundation;jarsigner` for current way of signing inside
artifact or `sign=Eclipse Foundation;gpg;<GPG_SIGN>` if signing was
implemented as GPG.
For SimRel, I think we can expect metadata to be reliable enough as
they're always provided by Eclipse projects from eclipse.org
<http://eclipse.org> domain, which is accessed via HTTPS.
As a bonus, with those signature informations in metadata, it would
become even possible, to eg show owners of the signature to users
before artifacts get actually donwloaded.
As I said, all this is currently brainstorming, explorative work,
nothing is planned at all. So as every brainstorming, additional ideas
or criticism are really welcome and even necessary! Mainly, I'm
curious about feedback on whether this seems useful, doable and if
this topic was already explored in the past.
I think verifying the premise that it will be okay not to ship signed
jars should be verified first.
Thanks in advance
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
_______________________________________________
p2-dev mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/p2-dev
