Hi all,
Thanks to Mikael (Barbero) for encouraging exclusion of any automated form
of trust at the moment, we're making some concrete progress here:
* artifacts provider can now attach PGP signatures to the p2 metadata and
p2 will ensure all those signatures are correct for the given artifact when
downloading it; installation will fail early if a signature is incorrect.
For the moment, public keys for verification current are also to be placed
in p2 metadata.
https://www.eclipse.org/eclipse/news/4.20/platform_isv.php#pgp-signature-verification
* With https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/179275
** An artifact is considered as *signed*, and installation won't show the
"unsigned" popup, if it has either internal signature info (with x509
certifacte) or if it has at least 1 PGP signature attached. Internal
signatures take priority over PGP ones (eg if internal signature is
present, we fully ignore PGP stuff)
** if an artifact in only signed by PGP, user will be prompted whether
they do *trust* the PGP signer public key or not. If they don't trust
enough keys to have all artifacts trusted, the installation will be aborted.
At the moment, it seems like a good 1st step towards embracing PGP more and
more where internal signatures don't apply well.
There are some known limitations which are actually keeping things safe for
a 1st iteration, at the cost of more required clicks:
* We don't ship any PGP key to be trusted by default
* We don't persist the trust in PGP keys: dialog to trust PGP will show up
every time there is a PGP signature, even if this one was trusted earlier
There are some other usability limitations which deserve improvement to go
mainstream:
* One cannot easily view/export a PGP key from the dialog, for verification
against other tools and services
* Dialog doesn't show whether a subset of PGP Keys is sufficient to
complete installation (eg 1 artifact may have multiple signatures, only 1
is necessary to be approved for installation to complete, dialog doesn't
show that and gives impression all keys need to be approved)
* The dialog doesn't give any form of hint about how to decide whether to
trust a key or net (eg check PGP key registries and so on); but it's also
the case for certificates apparently...
* We should offer a way to persist the trust, but that also means we should
offer way (preference page) to edit the trust store, and then to plug some
forms of checks against PGP key registries to allow warning users if a key
is revoked or whatever bad happens.
* We could persist the *known* keys (not meaning they're trusted), and ship
the IDE with a default set of known keys, and let p2 read those known keys.
That would allow to ship artifacts with signatures without having the
signature part of the metadata.
And the trickiest thing to consider: we should maybe have the UI helping
user in dealing with his "web of trust", eg inform user whether there is a
"path of trust" allowing to decide whether to trust one key as transitively
trusted by some other key.
And then, some more things to consider from the "production" side: when
consuming an OSGi bundle or p2 artifact from a Maven repository directly,
also import the PGP signature that's usually in the Maven repo into the p2
metadata for this artifact so the artifact would then be signed (but not
trusted unless user decides to trust the signer); and/or allow to add PGP
signature when importing a Maven artifact (so Eclipse Project X could PGP
sign a Maven artifact it ships, and if project X is trusted, it would let
p2 install the "external" artifact)
Cheers
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
