[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] Making p2 deal with (PGP?) signatures for artifacts in metadata
|
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
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.
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/p2-dev