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
signing plugin: use SHA512 instead of SHA1 when signing artifacts #10543
Conversation
|
Interesting case is SHA-512 might be faster on the modern hardware (SHA512 operates on 64 bit words0): https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly). So the checksum might default to SHA512 taking into account the security might be more important than tiny savings in terms of SHA256 vs SHA512 |
|
Just in case, gpg 2.2.11 defaults to SHA256: |
|
Hi @vlsi, I've been reading about your plugins/work. I really appreciate you pushing the security forward on this. I agree that it's important. Do you know if Maven Central requires SHA1 or will it be fine if artifacts are uploaded signed with SHA512? I just want to make sure we aren't breaking peoples upload process with these changes. |
|
@JLLeitschuh , this does not change the set of files that are uploaded to Central or whatever. This change alters the internal contents of For instance: There you see that the signature is using SHA512 digest, however you can clearly see that no So:
So I think the default could be just updated, and there's no need to make it configurable. Does that answer your question? |
|
Here's an example of Apache Maven-generated SHA256-based signature: https://repo1.maven.org/maven2/org/postgresql/postgresql/9.4.1208/ That artifact was deployed to Maven Central (2016-02), and no-one complained that they can't use pgjdbc (which is the official JDBC driver for PostgreSQL). |
|
Hi @vlsi, This makes sense. No reason not to go all the way to SHA512 in that case. Feel free to update your PR to do so. One other question. In your opinion, is our use of SHA1 without allowing users to configure that worthy of a CVE on our behalf. Is there a president you can find where this may be a case where it's worth issuing one? |
|
Well, there's https://www.cvedetails.com/cve/CVE-2005-4900/ , so it probably is worth registering a CVE. The case here is Gradle does not use consider PGP signatures (yet?), however users might not realize that Gradle-generated PGP signatures are as strong as SHA1 which is not that strong nowdays. So an attacker could replace a file which would still pass PGP signature verification. |
PGP signs a digest, so MITM is still possible provided an attacker can update the artifact in such a way that its SHA1 is intact. Relevant article is https://medium.com/@jonathan.leitschuh/many-of-these-gpg-signatures-are-signed-with-sha-1-which-is-vulnerable-to-a-second-preimage-attack-67104d827930 Signed-off-by: Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
|
Ironic that I wrote that comment about SHA1 no longer being resistant to hash collisions, but I didn't think to check what Gradle itself was using. I really appreciate you following up on this. CC: @melix This may be relevant to your work. |
|
This looks like a good change. I'm wondering if it wouldn't be worth adding the sha512 signature to Gradle Metadata, since we compute it... This can be done in a separate PR, though. |
|
@melix Can you create a card for this? |
|
@JLLeitschuh could you make sure this gets merged for 6.0? |
|
Working on the CVE issuance now. |
|
CVE-2019-16370 was assigned to this issue. |
|
@JLLeitschuh Is this something we need to mention in the release notes/upgrade guide? |
|
@lptr Working on it. |
PGP signs a digest, so MITM is still possible provided an attacker can update
the artifact in such a way that its SHA1 is intact.
Context
Relevant article is https://medium.com/@jonathan.leitschuh/many-of-these-gpg-signatures-are-signed-with-sha-1-which-is-vulnerable-to-a-second-preimage-attack-67104d827930
As you might know, Chromium does not trust SHA-1 signed certificates: https://www.chromium.org/Home/chromium-security/education/tls/sha-1
Gradle is often used to sign artifacts, so it would be nice to keep its default security level is up to date.
I'm not sure if this change needs to be represented in the documentation / upgrade notice.
AFAIK it should be backward and forward compatible, however it might make sense to clarify that "previous PGP signatures have SHA1 level of security".
I do not add tests in a hope that the code has already been covered.
Contributor Checklist
<subproject>/src/integTest) to verify changes from a user perspective<subproject>/src/test) to verify logic./gradlew <changed-subproject>:checkGradle Core Team Checklist