Maven Target location should promote the signature in the artifact metadata

[laeubi]

Currently, when consuming an artifact from maven repository with the maven target location, the artifact metadata misses the asc signature (if any).

[mickaelistria]

That should be optional: in the Eclipse world, we don't want to reuse existing signatures from the individual who did push to Maven Central, we prefer having Eclipse projects re-signing the artifact to indicate the project trusts the artifact. So usually, importing PGP signatures from Maven Central wouldn't be necesary nor desired.

[laeubi]

Each source should provide the information it contains, if platform decides to replace / ignore these it is still possible, but we should not enforce platform rules to every Tycho user.

[laeubi]

Anyways I think it would be cool to have config sections dedicated to target locations (e.g. directory, ui, maven, ..) we have something similar for the timestamp providers already.

For the maven location I thing the following would be useful to configure:

• if signatures should be fetched at all
• if public keys should be fetched
• if signatures should be verified

[laeubi]

Might be useful here:

• https://issues.apache.org/jira/browse/MNG-7560
• warning during artifact signature download s4u/pgpverify-maven-plugin#53

[laeubi]

@mickaelistria as you now added options to control (re) signing of artifacts, do you still think it should be optional or simply the default?

[mickaelistria]

It can be turned on by default, but we need a way to disable it. For example, in Eclipse projects participating in SimRel, we don't want to use random signatures, we want that Eclipse project do sign the artifacts they ship as a way to say "I, Eclipse XYZ, do trust this artifact", and we don't really mind about who signed it first. So we wouldn't want to include "random" signature in that stage.

[merks]

Note that because a p2 does not have access to a key server (by default) if we are going to record the signature, we'd better also record the public key because otherwise the signature generally can't be validated anyway. Of course then the thing doing the recording of the signature fetched from Maven will need access to a key server in order to determine the key of the signature, keeping in mind that key collisions are possible and should be properly handled to resolve the key ID to the correct key.