Re: [cbi-dev] Eclipse Foundation public PGP key?
This is a good place to ask this question, no worries.
If I understand correctly, the main motivation behind using GPG signatures rather than jarsigner is to avoid touching the jars. Is that right?
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.
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.
Some questions regarding your design:
- 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
- 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://bugs.eclipse.org/bugs/show_bug.cgi?id=263708 for the reasoning why using TSA was requested initially.
I guess this feeling that a chain of trust can be replaced by a web of trust comes from what maven central is doing (requiring a gpg signature to publish). My feeling is that the threat model is definitely not the same as with the one under which jarsigner/p2 have been designed. My first advice would be to first design a threat model and design your solution around it.
Finally, I'm definitely not a SME, so I'd suggest you reach out to some security experts to evaluate your designs.
Hope this helps.
Manager — Release Engineering and Technology | Eclipse Foundation
Not sure if this is the most appropriate mailing-list, but it's my best guess since it's about infra; feel free to redirect me someplace else if necessary.
We're investigating alternative approach to signing in p2. Nowadays standard is PGP and would like to enable some integration with PGP that can be useful to Eclpse projects.
One approach we're thinking about is to include in p2 metadata the PGP signtures and have a p2 processingStep to verify the signature matches a trusted one. We'd like to start by have the EF signatures as being trusted, similarly to how the x509 certificate is trusted. However, we don't have trust chain with paid certificates here, so we need to know in advance what's the key we trust.
Does Eclipse Foundation provide a public PGP key that we could use to verify signatures? I'm aware it does have some PGP keys to allow publishing to Maven Central from CI. Are all projects using the same key to sign (🤞yes)? If so, what is the public key?
Once we have a capability to verify the signature at installation, the next step would be creating a Tycho mojo to sign the artifacts and add signature in p2 metadata when building on Eclipse infra.
Thanks in advance!
cbi-dev mailing listcbi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cbi-dev
Description: Message signed with OpenPGP