If I understand correctly, the main motivation behind using GPG signatures rather than jarsigner is to avoid touching the jars. Is that right?
The 3rd-party jars, yes. The goal is to remove the need for repackaging and going through Orbit for external libraries that are already valid OSGi bundles and to find an alternative way to "trust" the external jars chosen by projects without touching them.
For Eclipse project jars, jarsigner is good and easy to use; I don't aim at changing that as I don't see room for improvement here.
I have the feeling that you want to replicate a Chain of Trust (à la SSL/TLS) with GPG. GPG is based on a Web of Trust concept and shall not be used to replicate Chains. It does not mean that GPG should be used to sign artifacts and use this system rather than jarsigner. I just want to outline that the implications of such change are rather broad, and it's easy to miss something that would make the whole solution much less secure that what it's aiming to be.
Yes, it's more or less my idea: can we for a given artifact build&resolve a "chain of trust" using PGP that resolves to a "root" cacert (eg Eclipse Foundation key).
To reply to your question, we have a "webmaster" GPG keypair and we provide to any project its own GPG keypair. We sign the project's public key we provide with the webmaster's key to initiate the web of trust. We advise committers to both sign webmaster's and project's public keys. We don't provide a single key to everyone because GPG is not meant to be used like that.
The webmaster's public key is
http://keys.gnupg.net/pks/lookup?op=vindex&fingerprint=on&search=0x9FA2B7299F51E543
OK, thanks
- How do you trust the webmaster key initially? If it becomes your effective root cacert, it needs to be trusted by the end user in some way. When you visit a website, you trust the website's certificate because you trust your OS (or the JVM) to have a non-tampered root CA list. If the root CAs are delivered by the website, it hard to trust anything. The only way to do this properly with GPG is to rely on the user's GPG keyring, hence requiring GPG to be installed on their system... And trusting a GPG key is not something to be considered lightly: it is easy to do typosquatting on public key servers. See https://www.gnupg.org/gph/en/manual/x334.html
In my current "vision" (which may be bad), I was imagining the webmaster key to be hardcoded in some bundle initially, making it an immutable keyring. Later, this may be expanded to allow users to add keys. But I imagine this as a further iteration.
- How do you handle time stamping? AFAIK, currently GPG does not support trusted signature timestamping. It means that you cannot trust a signature after the keys used to sign it has been revoked or has expired (while with current jarsigner signature, you can trust a signature if it has been made while the certificate was valid). This is a big issue, esp. in the case of a compromised key. See https://bI was assumugs.eclipse.org/bugs/show_bug.cgi?id=263708 for the reasoning why using TSA was requested initially.
That's a good concern. At the moment, I don't know. In Maven Central, there is a release date associated to the release. For p2, I have no clue of whether this can map to anything existing (yet?).
