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:
** 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
