Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some published artifacts have bad signatures [SPR-15623] #20182

Closed
spring-projects-issues opened this issue Jun 5, 2017 · 11 comments
Closed

Some published artifacts have bad signatures [SPR-15623] #20182

spring-projects-issues opened this issue Jun 5, 2017 · 11 comments
Assignees

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jun 5, 2017

Tom Zeller opened SPR-15623 and commented

Some Spring Framework 4.3.8 JARs have bad signatures - or maybe I'm just doing it wrong.

Is the proper fingerprint published in GitHub somewhere ?

For example, bad signature for spring-core-4.3.8.RELEASE.jar :

wget http://repo1.maven.org/maven2/org/springframework/spring-core/4.3.8.RELEASE/spring-core-4.3.8.RELEASE.jar
wget http://repo1.maven.org/maven2/org/springframework/spring-core/4.3.8.RELEASE/spring-core-4.3.8.RELEASE.jar.asc

or

https://repo.spring.io/release/org/springframework/spring-core/4.3.8.RELEASE/spring-core-4.3.8.RELEASE.jar
https://repo.spring.io/release/org/springframework/spring-core/4.3.8.RELEASE/spring-core-4.3.8.RELEASE.jar.asc

gpg --verify spring-core-4.3.8.RELEASE.jar.asc
gpg: assuming signed data in 'spring-core-4.3.8.RELEASE.jar'
gpg: Signature made Tue Apr 18 10:27:31 2017 CDT using RSA key ID D401AB61
gpg: BAD signature from "Bintray (by JFrog) bintray@bintray.com" [unknown]

But a good signature for spring-core-4.3.8.RELEASE.pom :

wget http://repo1.maven.org/maven2/org/springframework/spring-core/4.3.8.RELEASE/spring-core-4.3.8.RELEASE.pom
wget http://repo1.maven.org/maven2/org/springframework/spring-core/4.3.8.RELEASE/spring-core-4.3.8.RELEASE.pom.asc

gpg --verify spring-core-4.3.8.RELEASE.pom.asc
gpg: assuming signed data in 'spring-core-4.3.8.RELEASE.pom'
gpg: Signature made Tue Apr 18 10:27:23 2017 CDT using RSA key ID D401AB61
gpg: Good signature from "Bintray (by JFrog) bintray@bintray.com" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8756 C4F7 65C9 AC3C B6B8 5D62 379C E192 D401 AB61

Imported new signing key for 4.3.8 via :

gpg --keyserver hkp://pool.sks-keyservers.net --search-keys 0x379CE192D401AB61

For reference, here's 4.3.7 :

gpg --verify spring-core-4.3.7.RELEASE.pom.asc
gpg: Signature made Mon 20 Mar 2017 11:41:37 AM EDT using RSA key ID E457C53D
gpg: Good signature from "Spring Buildmaster buildmaster@springframework.org"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: E2AC B037 933C DEAA B7BF 77D4 9A2C 7A98 E457 C53D

and 4.3.6, whose key was revoked :

gpg --verify spring-core-4.3.6.RELEASE.pom.asc
gpg: Signature made Wed 25 Jan 2017 09:09:05 AM EST using DSA key ID 93185045
gpg: Good signature from "Spring Buildmaster buildmaster@springframework.org"
gpg: WARNING: This key has been revoked by its owner!
gpg: This could mean that the signature is forged.
gpg: reason for revocation: Key has been compromised
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 73FE 03B9 CB49 3113 DB54 89DE 23EF 3D2F 9318 5045


Affects: 4.3.8

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 6, 2017

Stéphane Nicoll commented

Thanks for the report, it looks like some signature haven't been updated. I've created an issue and I'll follow-up here when I hear back from them.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 6, 2017

Dave Syer commented

In case it matters, I see a different (valid) signature for 4.3.6, using the newer key (E457C53D). Maybe you are behind a caching proxy and it changed in the backend? The 4.3.8 problem seems unrelated.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 6, 2017

Tom Zeller commented

Hmm. The 4.3.6 artifacts signed with the revoked key were from our project's Maven/Nexus repository :

https://build.shibboleth.net/nexus/content/repositories/thirdparty/org/springframework/spring-core/4.3.6.RELEASE/spring-core-4.3.6.RELEASE.jar
https://build.shibboleth.net/nexus/content/repositories/thirdparty/org/springframework/spring-core/4.3.6.RELEASE/spring-core-4.3.6.RELEASE.jar.asc

We download artifacts from Maven Central, validate signatures, and then upload them to our repo.

Yes, the artifacts now available from Maven Central are signed with the newer key as you describe above.

The date on the Maven Central artifacts is 2017-01-25. We downloaded those artifacts from Maven Central and uploaded them to our Maven/Nexus repo on 2017-02-17, and I've verified those timestamps on disk.

https://issues.shibboleth.net/jira/browse/JPAR-56?focusedCommentId=25037&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25037

What's weird to me is that the .asc's from our repo and from Maven Central are different. I think they shouldn't be, unless the .asc's were re-published to Maven Central. I didn't think that was possible, but I've only used Sonatype OSSRH to publish to Central - of course I don't know if that's what Spring does.

Or maybe I'm confused, which is quite possible.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 6, 2017

Dave Syer commented

Our keys were compromised so we had to re-compute a bunch of signatures, and Sonatype let us do that because of the circumstances. That explains the difference between your cached copy and the one in Central for 4.3.6. We are still waiting for JFrog to see if they can explain the BAD signature on 4.3.8. Note that they managed to sign spring-boot 1.5.3 for us without any problems using the same key, so whatever happened it was in a pretty small time window that happened to coincide with Spring 4.3.8 GA.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 7, 2017

Stéphane Nicoll commented

Thanks a lot for reporting the issue. The signatures have been fixed and we've restaged them on central. They should show up soon.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 8, 2017

Tom Zeller commented

FWIW still seeing bad/invalid signatures on 4.3.8 from Central and repo.spring.io.

Is there any public information about the key compromise ?

Is the public signing key or fingerprint posted somewhere ?

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 8, 2017

Dave Syer commented

I see the same bad signatures on central (so I guess we are still waiting for the patches to be deployed or maybe some caches to refresh). But repo.spring.io has no signatures for 4.3.8, so I'm not sure where you saw those.

The public keys used to sign the jars are all in the standard key servers (you can download them with gpg --recv-keys). As far as I know we don't post them anywhere else (and the newer jars are signed by Bintray anyway)..

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 8, 2017

Tom Zeller commented

But repo.spring.io has no signatures for 4.3.8, so I'm not sure where you saw those.

From here :

https://repo.spring.io/release/org/springframework/spring-core/4.3.8.RELEASE/spring-core-4.3.8.RELEASE.jar
https://repo.spring.io/release/org/springframework/spring-core/4.3.8.RELEASE/spring-core-4.3.8.RELEASE.jar.asc

The public keys used to sign the jars are all in the standard key servers (you can download them with gpg --recv-keys). As far as I know we don't post them anywhere else (and the newer jars are signed by Bintray anyway)..

Right, I understand. We use --keyserver-options "auto-key-retrieve no-include-revoked" when validating, FWIW.

But what I'm really looking for is a way to "trust" that indeed the key used to sign the artifacts is authoritative.

For example, we asked[1] Jetty to publish their signing keys, and now they do[2].

[1] https://dev.eclipse.org/mhonarc/lists/jetty-dev/msg02823.html
[2] https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/KEYS.txt

It would be great if Spring/Pivotal would do something similar, especially now that a third-party is signing the artifacts. For example, we publish our keys to http://shibboleth.net/downloads/PGP_KEYS.

Thank you for taking time to answer my questions and considering our suggestion,
Tom

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 8, 2017

Dave Syer commented

I see https://repo.spring.io/release mirrors the Central arrtifacts, so that's why it's the same (it's a virtual repository). The physical repository is https://repo.spring.io/libs-release-local (which doesn't have signatures for Spring 4.3.8 and above because JFrog changed the way they do thing s in artifactory).

If you want the see the public key that we own on a website somewhere that's probably reasonable. Please open a separate ticket for that though, and for the Bintray one you'd have to open a ticket with Bintray/JFrog, not Spring.

If you think that we should sign jars with our own key you can certainly make that argument here, but I don't know of any compelling reason to do so.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 8, 2017

Tom Zeller commented

Ah, didn't know that repo.spring.io was a virtual repository - makes sense now.

I agree, I guess it doesn't really matter which key (Spring's or JFrog's) is used to sign the artifacts, but we would like to bind/pin artifacts to a key. For example, there's a Maven plugin[1] to validate signatures, and it takes a map of the form :

groupId:artifactId:version=pgpKey

So if Spring says that the Bintray/JFrog key is authoritative, then we would bind/pin/trust that key. I'd be happy to open a new ticket for Spring to publish their key on a website somewhere, but if that key isn't used to sign artifacts anymore then I don't think that helps this particular request moving forward. Given that a third party is now signing the Spring artifacts, I am thinking that what Jetty did would be helpful here too, and that's adding KEYS.txt to GitHub containing the fingerprint of the signing key. But, given the number of projects in https://github.com/spring-projects/, that does seem a little onerous. For now, I'll see if JFrog publishes their signing key, and if not I'll try and ask that they do.

Hope I'm still making sense, thanks again.

[1] https://www.simplify4u.org/pgpverify-maven-plugin/check-mojo.html

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 10, 2017

Dave Syer commented

Still making sense. The 4.3.8 artifacts in Central have valid signatures as of now (https://issues.sonatype.org/projects/OSSRH/issues/OSSRH-32173).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants