| [platform-dev] PGP Signing Question? |
Hi,
I've been investigating the new PGP signing support. To test it,
I install the Eclipse Test Framework from the 4.23 I-Builds
because that includes several bundles that are PGP signed:
As a result of this action, the following dialog pops up asking me if I trust "these signers":
There is no information in the name column. I believe it's populated by org.eclipse.equinox.internal.p2.ui.dialogs.TrustCertificateDialog.createUpperDialogArea(Composite) like this:
java.util.List<String> users = new
ArrayList<>();
pgp.getUserIDs().forEachRemaining(users::add);
return String.join(",", users); //$NON-NLS-1
Looking at the implementation, I don't see how a PGPPublicKey
ever ends up with associated "user IDs". (And the Details...
button is only enabled for a selected X509Certificate.)
Is there a bug here? I don't think we can expect the users to
grant trust on the basis of some hexadecimal numbers...
----------------------------------
Where/what is the best way for asking question and for discussing
the implementation details? I posted on platform-dev because the
entire platform is affected by these design decisions, but perhaps
I should restrict this to p2-dev or elsewhere?
For example, the fact that the keys are stored as repository
properties, rather than as properties on the artifacts, seems
quite problematic and will tend to break downstream applications.
We've already seen that this breaks mirroring because mirroring
doesn't mirror repository properties nor should it in general do
so. It also breaks the installer (i.e., in general the use of p2
agents with a shared p2 bundle pool). It will no doubt impact the
aggregator as well. Every consumer will need to know to "copy and
merge" this specific repository property (but not any other
repository properties) when copying/mirroring artifacts.
I expect there is a concern about the size of many such the
duplicates keys, but with both jar and *.xz compression that isn't
really so much a problem. I.e., 1000 copies of the key has
minimal impact on the size compressed artifacts as seen here where
the artifacts.xml has 1000 copies of the key:
-rw-r--r-- 1 merks 197609 823870 Jan 3
11:31 artifacts.original.xml
-rw-r--r-- 1 merks 197609 119252 Jan 3 11:32
artifacts.original.xml.jar
-rw-r--r-- 1 merks 197609 89796 Jan 3 11:37
artifacts.original.xml.xz
-rw-r--r-- 1 merks 197609 1264772 Jan 3 11:14 artifacts.xml
-rw-r--r-- 1 merks 197609 122441 Jan 3 11:33 artifacts.xml.jar
-rw-r--r-- 1 merks 197609 90008 Jan 3 11:38 artifacts.xml.xz
The implementation sort of already assumes/supports it as an artifact key in org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.findKey(long, IArtifactDescriptor) like this:
// in case keys from artifact were not imported yet in
keystore, add them
PGPSignatureVerifier.KNOWN_KEYS
.addKeys(artifact.getProperty(PGPSignatureVerifier.PGP_SIGNER_KEYS_PROPERTY_NAME));
return PGPSignatureVerifier.KNOWN_KEYS.getKey(id);
And even the org.eclipse.equinox.p2.tests.engine.CertificateCheckerTest.testPGPSignedArtifactUntrustedKey() test works that way...
Regards,
Ed
