Some published artifacts have bad signatures [SPR-15623] #20182
Comments
|
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. |
|
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. |
|
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 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. 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. |
|
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. |
|
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. |
|
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 ? |
|
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 |
|
Tom Zeller commented
From here : https://repo.spring.io/release/org/springframework/spring-core/4.3.8.RELEASE/spring-core-4.3.8.RELEASE.jar
Right, I understand. We use 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 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, |
|
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. |
|
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 |
|
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). |
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
The text was updated successfully, but these errors were encountered: