Assess and Improve the Platform's p2 PGP Signing Infrastructure
This issue describes the current state of the Eclipse Platform's PGP support. This description will be edited to keep it up-to-date. As of Eclipse 4.23 RC1, the PGP implementation is functionally complete and the Eclipse Installer has been upgraded to support installing such content.
The Eclipse PMC has decided to use PGP signed artifacts in their own repositories for 4.23 (2022-03), so the Planning Council has little choice but to accept a rollout for 2022-06, though on the condition that the implementation is functionally complete and usable at the end of the current release cycle. Currently the Platform's PGP signed artifacts are not ones that are delivered to the release train, so there is time to refine the current implementation during the 4.23 development cycle.
As part of the PGP implementation, the check trust phase of p2 augmented the certificate checker to check not just for unsigned content and unrooted certificates (i.e., artifacts signed with a certificate for which the chain of trust is not rooted on a certificate in Java's cacerts). There have been a number of bugs related to this central implementation aspect, including the following:
- Bug 577863 NPE because there is no self-profile. The p2 director application fails to install PGP signed content.
- Bug 578161 NPE because there is no self-profile; the profile being provisioned should be used, not necessarily the self profile.
- Bug 575541 Verification fails silently because PGP Keys can't be located.
One very problematic design aspect of the overall design is the way in which the PGP keys are made available to clients. The existing design stores (Tycho <= 2.6) and fetches (Eclipse <= 4.22) the keys as artifact repository properties, although the implementation also looks them up as artifact properties. This is problematic because artifacts are generally "mirrored" from one location (artifact repository) to another, which doesn't always copy the artifact's properties, and typically never copies the artifact repository properties because these are generally specific to the original location of the repository itself. The effect is that p2's mirror application does not mirror the keys at all. In general, any artifact transported to an artifact repository local to the client no longer knows the keys, leading to problems like Bug 575541, and often even the signatures are lost. With Tycho 2.7 and Bug 578023 to use Tycho 2.7 in the Platform's builds, the keys are now stored as artifact properties.
This problematic aspect has been fixed via Bug 578322 by ensuring that the target artifact's metadata is always updated to include both the signature and the key that was used in combination with that signature to verify the content. So regardless of where/how the key is originally located---Bug 578322 also supports locating key via a key server---the key will be available directly on the artifact metadata of the target. This also allows the About dialog to display information about the key used on any of the PGP signed artifacts as implemented by Bug 578166 and allows artifacts with missing keys to be treated as unsigned content.
Via Bug 578322, support was implemented for more flexible management of PGP keys. Via a service registration, access to zero or more key servers can be enabled as well as access to the local GPG pubring. Via key server access, web-of-trust information can be presented to the user and key revocation verification can be supported. Fully leveraging this support is pending Eclipse.org providing a key server.
A remaining problematic design aspect is that the same artifact (with the same artifact key) can have different (artifact metadata) properties, and, in particular, can be signed by different keys (from different projects). This is of course inherent in the design nature of external signatures. The net effect though is that once an artifact is transported to a local, client-side, artifact repository, its signing properties cannot be changed. Moreover, if multiple source artifact repositories are involved during provisioning with multiple different artifact instances (different artifact metadata properties) for the same artifact, which "instance" with which properties/metadata is actually transported and recorded is arbitrary. For the release train repository, it was proposed during Planning Council discussions that PGP signed artifacts could be resigned to reduce the number of involved keys.
There were a number of bugs and usability issues with the trust certificate dialog (i.e., the dialog that displays to the user the PGP keys that are not-yet-trusted) that are currently being addressed:
For, Bug 578024 there have been significant improvements and I believe we have complete support for web-of-trust details (when available) and support for displaying the artifacts for which the trust dialog is opened, which also applies to unrooted certificates. The other two issues have been fixed. Also, support for saving trusted unrooted certificates has been implemented via [Bug 578653](Bug 575984.
The p2 framework has been extended for 4.23 to provide an extension point for contributing so-called trusted PGP keys, i.e., keys that will be trusted without prompting the user:
One might question this as a security loop hole, but it's important to note that if the user installs something that is ill-behaved, it's highly likely that they will have much bigger problems than trusting untrustworthy PGP keys during subsequent updates.
The Platform has used this mechanism to trust its own PGP signing key:
- Bug 578688 - Ship Eclipse project PGP keys as trusted by default
The Install/Update → Trust preferences page allows users to manually add keys to be trusted. This page also shows the keys contributed via extension point. It needs to properly handle the two different ways that trusted keys are added.
Both the above issues have been addressed.
For yet-to-be-determined reasons, the PGP sub-key used for signing is based on a key that is missing the signature by the Eclipse Webmaster <webmaster@eclipse.org> PGP key and this appears to be a general issue with our ci-infrastructure:
Ideally the current PGP implementation would be enhanced to make use of the web-of-trust signatures such that any key verifiably rooted on the Eclipse Webmaster <webmaster@eclipse.org> PGP key (or any trusted key) would be implicitly trusted, but unfortunately the currently-deficient signing key does not contain that information to fully implement that.
I believe the signature-poor keys is a limitation of GPG's mechanism for exporting keys to the application programmer as used by Tycho to embed in the p2 metadata. Via key server support, enhanced web-of-trust information can be presented without this enriched information being available in the p2 metadata.
Another problem that has been fixed is that PGP Key IDs are not necessarily unique but the original implementation assumed uniqueness:
Even if this isn't a security issue, which I believe is the case because a "spoofed" key will not verify the signature of an artifact, it was nevertheless problematic. This bug was addressed while providing the enhanced key server support. In the case of key ID collisions, each colliding key will be used by the PGP signature verifier to verify the content, and one of the keys must successfully verify the content; that key is recorded in the artifact metadata as described previously.
One detail of the current implementation (looking up trusted keys in profile properties) appears to be insecure:
This has been fully disabled in favor of contributing keys via extension point.
Some of the documentation could be improved:
These improvements have been made, but more could be done, particularly with respect to key servers and providing users with better information (a listing) of keys used by Eclipse projects.
From my personal point of view, I feel that the 4.23 released version of the Eclipse Platform will provide reliable, secure, and usable infrastructure to enable broader adoption of PGP signing as an alternative to jar signing. But I am not a security expert (nor am I lawyer for that matter).
I have successfully completed support for installing PGP signed artifacts via the Eclipse Installer so that too is ready for delivery for the 2022-03 release.
Background
- gnupg.org advice on public key use
- apache.org advice on public key use
- OpenPGP Message Format RFC
- OpenPGP HTTP Keyserver Protocol
Trusting a PGP public key involves verifying information about that key, e.g., based on information that is available via a key server. For example, when an artifact is PGP signed by the Eclipse Platform project, the fingerprint of the PGP public key used to sign that artifact is displayed to the user as a large hexadecimal number, e.g., 9E3044071B758EBCB7E45673700E4F39BC05364B, which is effectively a link available on any key server. From that link, the user can discover that this key is a subkey of the "Eclipse Platform Project platform-releng-dev@eclipse.org" key and can discover that this key in turn is signed by the "Eclipse Webmaster webmaster@eclipse.org"'s public key. In this way, the user can explore the publicly visible "web of trust" associated with the artifact's signing key.
But anyone can create a key with any associated user ID, so simply reading user IDs is not sufficient to ensure that the artifact is in fact signed by whom you think. Hence the lack of a definitive answer on how to make trust decisions.
I've opened the following issue requesting support for an Eclipse-hosted key server:
eclipsefdn/helpdesk#797 (closed)
This is a statement of requirement by the IDE Working Group Steering Committee:
- Issue 650 artifacts made available at the Eclipse Foundation are verifiably the ones built by respective projects.
This document contains an initial description of the design but is significantly outdated:
Tycho
Tycho provides tycho-gpg:sign-p2-artifacts for producing PGP signatures. It is used by the Eclipse Platform Build.