assemble-maven-repository should include PGP signatures in the P2 site

[laeubi]

As P2 support PGP signatures as an alternative to code signed artifacts, and maven artifacts that are deployed to maven central are PGP signed already we should add this information to prevent any "resign" requirements later on.

[laeubi]

Currently there is some code that downloads the PGP signature via maven (but not included yet). Before we enable this for reactor projects we might need to find a different solution.

@mickaelistria as your are familiar with the p2 PGP stuff, can you give a hint how to include a signature? Is there a special 'PGPAdvice' that could be used?

I also wonder if the PGP signature is something that is generated and then simply deployed as a regular artifact or if this is generated in the process while actually uploading the artifact to the maven-repository?

[mickaelistria]

This is not only for assemble-maven-repository; but for everything that fertches remote Maven artifacts (eg bundles cominf from pomDependencies=consider ot from fhe Maven locations in .target).
See https://www.eclipse.org/eclipse/news/4.20/platform_isv.php#pgp-signature-verification . PGP signatures are properties to be added to the artifact entry of artifacts metadata. I imagine there is a possibility to use some PropertyAdvice; not sure about those can be used for artifact metadata.
One thing to consider with PGP is trust: imagine Platform ships an Apache artifact, it would atill be worth having Platform pgp-sign it so it could be trusted by default inthe Eclipse context. So re-signing is not necessarily a bad thing and can even be desirable.

[laeubi]

PGP signatures are properties to be added to the artifact entry of artifacts metadata. I imagine there is a possibility to use some PropertyAdvice; not sure about those can be used for artifact metadata.

So what is the usual way to add such signatures? Editing the file directly?

One thing to consider with PGP is trust: imagine Platform ships an Apache artifact, it would atill be worth having Platform pgp-sign it so it could be trusted by default inthe Eclipse context. So re-signing is not necessarily a bad thing and can even be desirable.

Shouldn't it work in a way that Platform trusts Apache and thus an Apache artifact would be trusted trough web of trust? Beside that 're-signing' was more referred here as the process of taking an artifact from an arbitrary source and code-sign it with the Eclipse codesigning certificate, one thing that could be avoided when using the PGP trust if I have understand that correctly...

[mickaelistria]

So what is the usual way to add such signatures? Editing the file directly?

All that PGP story is still too young and immature to pretend any workfow is "usual".
But indeed, at the moment, editing the content.xml file directly is the only way.
A dedicated p2 publisher advice taking the private keys to sign with as input would be a good addition.

Shouldn't it work in a way that Platform trusts Apache and thus an Apache artifact would be trusted trough web of trust?

Te Web Of Trust is not implemented in the Platform so far, and even if web of trust exists, it's not something to automate but more something to use as hints for users to decide whether to trust or not.

Beside that 're-signing' was more referred here as the process of taking an artifact from an arbitrary source and code-sign it with the Eclipse codesigning certificate, one thing that could be avoided when using the PGP trust if I have understand that correctly...

PGP signature is an external way of doing code signing, which is capable of resigning; I think resigning is actually interesting for Eclipse case as explained in my previoys comment.

[laeubi]

A dedicated p2 publisher advice taking the private keys to sign with as input would be a good addition.

okay, thanks for clarification, I'll take a look if I can create one then for this purpose

PGP signature is an external way of doing code signing

Can you explain this more? I must confess I have thought about that the actual jar file/artifact is signed an not the individual class files as it is done with traditional codesigning (is the signing information also available at runtime?)

[mickaelistria]

Can you explain this more? I must confess I have thought about that the

actual jar file/artifact is signed an not the individual class files as it is done with traditional codesigning (is the signing information also available at runtime?) Ok, I misunderstood the question. PGP is used to signed jars/artifacts. Signature information is available at install-time and can be available at runtime through p2 profile details. It is "external" in the sense that unlike jarsigner, pgp-signing the jar doesn't modify the jar in any way, so it's much easier to allow multiple signatures from multiple sogners to happen at different times (eg the producer signs at publication, and fhe consumer also signs it to declare additional trust).

…

-- Mickael Istria Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> developer, for Red Hat Developers <https://developers.redhat.com/>

[laeubi]

@mickaelistria I have some more question, looking at your gpg-repository signer it does two things:

1. sign each artifact and attach the signature as a property
2. add the public key of the signer to the repo properties

Is the second part optional and key-list (e.g. MIT Keylist used by maven) can be used instead of specify the key? Does it mean that each artifact needs to be signed with the same key or can we have multiple ones?
Because I would have expected, instead of a single property pgp.publicKeys, ones in the form pgp.publicKeys.<keyid> so we can have multiple ones..

[mickaelistria]

Is the second part optional and key-list (e.g. MIT Keylist used by maven)

can be used instead of specify the key? No, it's not optional. p2 doesn't relt on keyserver, so the signers' keys needs to be declared.

Does it mean that each artifact needs to be signed with the same key or

can we have multiple ones? Each artifact can be signed by one or multiple keys; and they don't have to be the same ones for all artifacts.

Because I would have expected, instead of a single property

pgp.publicKeys, ones in the form pgp.publicKeys.<keyid> so we can have multiple ones... The pgp.publicKeys repo property can include multiple public keys; using the typical `gpg export --armor` command with multiple keys defined.

…

-- Mickael Istria Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> developer, for Red Hat Developers <https://developers.redhat.com/>

[laeubi]

P2 doesn't relt on keyserver,

Are there any plans to support this? I ask this because specifically for maven artifacts it seems that the MIT Key server is a requirement to upload artifacts and thus this one seems a good starting point. And especially if it comes to revocation of keys or expired key, statically embedding public keys into the metadata "forever" might be problematic.

If Eclipse plans to go towards PGP it even would be good to have an eclipse-key server to allow/require e.g. project-commiters to publish a PGP key there also (similar to ECA services).

The pgp.publicKeys repo property can include multiple public keys

okay that makes it a bit more complicated to enhance existing repos but for sure is not an issue when creating one from scratch like done here.