Please publish PGP signing keys publicly

[ghost]

This is a follow-up to issue gh-20182.

Could Spring please publish the public PGP keys used to create artifact signatures so that they are available via https download from an official Spring site?

That way users have a way to reliably verify the authenticity of downloaded artifacts.

[rstoyanchev]

Maven requires those to be published (see "Distributing Your Public Key" under https://central.sonatype.org/pages/working-with-pgp-signatures.html), and can be downloaded. For example:

$ gpg --keyserver pool.sks-keyservers.net --recv-key 9A2C7A98E457C53D
gpg: key 9A2C7A98E457C53D: public key "Spring Buildmaster <buildmaster@springframework.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

[ghost]

@rstoyanchev I don't think you've understood the problem I'm facing here yet. You need to understand that anyone can upload a key to the public keyservers, and it can be associated with any email address. You gave the example of searching for the key on pool.sks-keyservers.net:

You can see that the key has not been signed by anyone! There is no indication that this key is legitimate. If an attacker wanted to carry out a supply chain attack, this is what can happen: replace the artifacts on Maven with malicious ones, and also upload signatures of the malicious artifacts using a PGP key that the attacker controls. Then upload the public key to the keyservers, and bingo! If users follow your policy, they will trust the malicious artifacts because the only requirement you put on trusting a key is that it exists on a public keyserver.

Spring needs to indicate the correct key for signing Maven artifacts, so that users can trust those key(s) and no others. Another way would be to leverage the PGP Web of Trust by having other people sign your PGP key, but as I pointed out, that has not been done here.

[ghost]

Here is an example of someone doing the correct thing:

https://pivotal.io/security
(See the section "Reporting a vulnerability".)

Notice that the Pivotal security team publishes the fingerprint of their PGP key on a website they own and which is protected by https. As far as I know, Spring has not published fingerprints (or better yet the public keys themselves) anywhere for the Maven signing keys.

[bclozel]

Hi @EricPetersonIBKR - that's a good question (and the latest news point to this very problem).

The point you're making with our official security email channel is not the exact same thing, because here the key is required to encrypt any email sent to that email address. You don't strictly need such a key to consume Spring artifacts, or at least this feature is not supported (as far as I know) natively by build tools.

That's an interesting point still and we could publish that information on https://spring.io or somewhere else. It could be also interesting to provide information about how to check for those at the build level. It seems that there's an existing Maven plugin but I'm not aware of any solution for Gradle. How would you enforce such checks in your organization?

[ghost]

@bclozel for now in our case, imports of 3rd party software require manual checks, so that's why I'm bugging you guys here instead of a PGP Key Bot or similar. :)

It would be great if Sonotype made this process more friendly to automation, but what they have actually done is just make it very easy to upload PGP signatures but then almost no one publishes what the correct keys are. That instills a false sense of security in users. The mere presence of a valid PGP signature doesn't mean the artifact is legitimate unless you can also verify that the signing key is controlled by the project maintainers.

Here is another example of doing the right thing:

https://www.elastic.co/guide/en/kibana/current/rpm.html
(See "Import the Elastic PGP Key".)

Unless there is an official location, controlled by Spring, that publishes what the correct keys are, the PGP signatures have no value. Possibly less than no value: users have no way to verify that the key is correct, but they may mistakenly trust the signatures anyway.

[ghost]

@bclozel that said, I fully expect to automate the process of artifact verification as we have more resources to do so. To do that right though, we will need to decide which keys to trust and right now there is not a good way to do that in a fully automated way. So far in my experience, it requires a lot of effort contacting maintainers and asking for verification.

The Apache family of projects is a notable exception, they do a good job of publishing their maintainer PGP keys on their websites, which are protected by https.

Anyway, the point is that Spring could also set a good example here and get us one step closer to making it easier to automate securing the software supply chain. :)

[vlsi]

I've implemented Gradle plugin to verify PGP/checksums for dependencies, and it turns out SpringFramework indeed misses the official PGP keys.

Certain artifacts are signed though:

apereo/cas#4256

    <!-- It is a cut from the generated checksum.xml -->
    <trusted-key id='9a2c7a98e457c53d' group='org.springframework.boot' />
    <trusted-key id='257d4510e2e11827' group='org.springframework.retry' />
    <trusted-key id='257d4510e2e11827' group='org.springframework.security' />
    <trusted-key id='9a2c7a98e457c53d' group='org.springframework.shell' />
    <trusted-key id='51a00fa751b91849' group='org.springframework.vault' />
    <trusted-key id='9a2c7a98e457c53d' group='org.springframework.webflow' />
    <trusted-key id='9a2c7a98e457c53d' group='org.springframework.ws' />

[slawekjaranowski]

As I see

• spring-framework from version 5.3.1
• spring-boot from version 2.4.0

use Bintray Key, I detected it in my project, where I have verification for pgp keys used by artifacts

[slawekjaranowski]

There is a new key?
https://keyserver.ubuntu.com/pks/lookup?search=0x48B086A7D843CFA258E83286928FBF39003C0425&fingerprint=on&op=index

[bclozel]

Yes, I can confirm we have created this new key and will use it for the next releases (it has been used already for the releases performed this week).

[iay]

@bclozel @rstoyanchev What is needed by other projects which want to actually use artifact signatures to secure their software supply chain is that the Spring project publish the signing keys independently somewhere so that we can confirm a link between the artifacts and the keys.

Downloading an unsigned key from a key server doesn't help us.

Having someone (even a project member) refer to "this new key" in an issue comment isn't enough either.

One convention used by other projects that you might consider would be to to include the public keys in a KEYS file within the project repository itself, or publish the full fingerprints in your reference documentation. It would be really helpful if this could be arranged. Otherwise, adopting 6.0.5 requires a leap of faith on the part of dependent projects.

[bclozel]

@iay adding a KEYS file to this repository does not scale, as we'd need to add it to all repositories in the spring-projects GitHub org. We could publish it at https://spring.io/KEYS, but I still find that sub-optimal. I'm also seeing third party projects trying to gather all that information in a single place, but to me this only adds a new independent actor in the game and thus makes the supply chain weaker.

Related issues linked here point to specific web pages on the official website, a KEYS file in the repo, a link to the key in the README.md or nothing at all. It's not consistent and it's hard to automate on the consumer side.

I'll take this discussion to the broader team.

[vlsi]

This might be relevant for inspiration: https://kotlinlang.org/docs/security.html

[iay]

@bclozel It has been a few weeks, and 6.0.6 is out now as well so we've now had two releases where we have no way to rationally validate the Spring Framework artifacts. Can I ask if there is likely to be any progress on this front soon?

It's not consistent and it's hard to automate on the consumer side.

I missed this statement the last time round. Just to be clear, we're not looking to you to produce some kind of automated solution to the software supply chain problem. We expect, and indeed require, human interaction in evaluating the signing keys that we accept for specific artifacts (based on Maven groupId values). All that is required from your end is publication of your signing key in a way that we can see is an official publication of the project rather than some kind of personal statement (not that we've seen that either). It doesn't need to be any more complicated than publishing the key on your web site, or in the repository.

[bclozel]

@iay thanks for the reminder - I've submitted a PR internally for publishing this information on the official website. I'll report back here when it's published.

[bclozel]

We've published relevant information here: https://spring.io/GPG-KEY-spring.txt
This link has been added to the SECURITY.md file at the root of this repository.

[vlsi]

@bclozel , would you please adjust the recommended command in GPG-KEY-spring.txt so it includes full fingerprint?

Currently, the file suggests --recv 928FBF39003C0425, however, short key ids are inherently insecure:

• https://evil32.com/
• https://evil32.com/examples.html