tycho
tycho copied to clipboard
tycho-p2-repository:assemble-repository bundles **ALL** public keys from the local keyring if `keyname` not set
The tycho-p2-repository:assemble-repository generates the .asc files and I can also see the gpg.* properties appear in the artifacts.xml - but for some reason the pgp.publicKeys is HUGE - and the artifacts.xml gets blown up to like 30MB.
I have decoded what it puts there, and it is ALL public keys from my keyring!
The includePGPSignature from tycho-p2-repository:assemble-maven-repository only embeds the public key of my default identity.
<packaging>eclipse-repository</packaging>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-gpg-plugin</artifactId>
<version>${tycho-version}</version>
<executions>
<execution>
<id>sign-p2-artifacts</id>
<goals>
<goal>sign-p2-artifacts</goal>
</goals>
</execution>
</executions>
</plugin>
The command line that the plugin generates in org.apache.maven.plugins.gpg.ProxySignerWithPublicKeyAccess#getPublicKeys is:
gpg --export --armor
... and that indeed exports the whole public keyring. I don't find a way in the gpg man pages of specifying that only the default signing key should be exported. Neither do I find an option to figure out what the default signing key is. It might be necessary to first sign the artifacts and then inspect the signature for the key ID and then fetch the public key for the specific key ID.
@mickaelistria can you take a look at this?
The workaround is to add the keyname parameter in the tycho-gpg-plugin configuration - but that kind of makes the build specific to the system of the release manager - or it requires the release manager to explicitly set an extra property when doing a release build, which is inconvenient.
@mickaelistria can you take a look here? I'd like to spin a service release next week (what will include a PGP fix as well) so it would be great if we could include a fix to this as well.
I don't think I'll have time to work on it soon. The time I can devote to coding (not much these days because of all other activity) is currently fully on m2e-wtp and Maven metadata generation for Eclipse Platform
@reckart Please check the PR attached to #1706. I am a bit puzzled by this report, because you talk about tycho-p2-repository:assemble-repository in the headline, but in your description you also mention tycho-gpg-plugin. Both are kind of orthogonal...
IMHO the former will never add any public key(s) to the metadata.
@laeubi This issue is fixed now.
@reckart Please check the PR attached to https://github.com/eclipse-tycho/tycho/issues/1706. I am a bit puzzled by this report, because you talk about tycho-p2-repository:assemble-repository in the headline, but in your description you also mention tycho-gpg-plugin. Both are kind of orthogonal... IMHO the former will never add any public key(s) to the metadata.
@kwin thanks for looking into this. So, what do I need to do to have the artifacts in an update site generated by tycho-p2-repository-plugin properly signed such that Eclipse will recognize the signature?
The tycho-p2-repository-plugin has a parameter includePGPSignature, but the tycho-p2-repository-plugin does not seem to have that. So I assumed that the tycho-gpg-plugin must be used to add the signature, but it appears that does not work either.
Probably it helps to look at this simple integration test which
https://github.com/eclipse-tycho/tycho/tree/master/tycho-its/projects/gpg.sign.p2.basic
Especially this:
https://github.com/eclipse-tycho/tycho/blob/master/tycho-its/projects/gpg.sign.p2.basic/site/pom.xml
@merks Thanks. Apparently some time back, I was able to set up a minimal example using both tycho-p2-repository-plugin and tycho-p2-repository-plugin that had proper signatures when installing the artifacts into Eclipse (see discussion). Unforunately, I never got it to work with Apache UIMA :( Also, I am forced for the time being to downgrade to Tycho 2.7.5 because of problems with Tycho 3. And as far as I could see, the issue that all keys are embedded if no keyname is set was not fixed in the 2.x line.
If you have any further ideas, best comment on the discussion.
Indeed it is not back ported. If I recall correctly, it's not even in 3.x...