Open melix opened 3 years ago
Thanks for the suggestion. This is definitely something we should consider supporting long-term.
We've been hesitant to add any check around signature verification so far, mostly because there does not seem to be a well rounded story around key management/discoverability/revokation. We need to take a second look.
Related link for npm: https://docs.npmjs.com/verifying-the-pgp-signature-for-a-package-from-the-npm-public-registry
There are other ongoing efforts like sigstore that are relevant.
Any feedback, suggestion or ideas are welcome!
I think we can work on Dependency verification check https://docs.gradle.org/current/userguide/dependency_verification.html, probably the signature verification later.
<?xml version="1.0" encoding="UTF-8"?>
<verification-metadata>
<configuration>
<verify-metadata>true</verify-metadata>
<verify-signatures>false</verify-signatures>
</configuration>
</verification-metadata>
@laurentsimon Thoughts?
I think we can work on Dependency verification check https://docs.gradle.org/current/userguide/dependency_verification.html, probably the signature verification later.
<?xml version="1.0" encoding="UTF-8"?> <verification-metadata> <configuration> <verify-metadata>true</verify-metadata> <verify-signatures>false</verify-signatures> </configuration> </verification-metadata>
@laurentsimon Thoughts?
Agreed it's a great idea. We can start with the integrity part and implement it in the Pinned Dependency check. Is it what you had in mind too, @naveensrinivasan ?
I think we can work on Dependency verification check https://docs.gradle.org/current/userguide/dependency_verification.html, probably the signature verification later.
<?xml version="1.0" encoding="UTF-8"?> <verification-metadata> <configuration> <verify-metadata>true</verify-metadata> <verify-signatures>false</verify-signatures> </configuration> </verification-metadata>
@laurentsimon Thoughts?
Agreed it's a great idea. We can start with the integrity part and implement it in the Pinned Dependency check. Is it what you had in mind too, @naveensrinivasan ?
Yes, that's what I had in mind. For the first pass we check if the file exists and if it has <verify-metadata>true</verify-metadata>
flag enabled.
I think we can work on Dependency verification check https://docs.gradle.org/current/userguide/dependency_verification.html, probably the signature verification later.
<?xml version="1.0" encoding="UTF-8"?> <verification-metadata> <configuration> <verify-metadata>true</verify-metadata> <verify-signatures>false</verify-signatures> </configuration> </verification-metadata>
@laurentsimon Thoughts?
Agreed it's a great idea. We can start with the integrity part and implement it in the Pinned Dependency check. Is it what you had in mind too, @naveensrinivasan ?
Yes, that's what I had in mind. For the first pass we check if the file exists and if it has
<verify-metadata>true</verify-metadata>
flag enabled.
@laurentsimon What about the score calculation? How should this affect the score?
Yes, that's what I had in mind. For the first pass we check if the file exists and if it has
<verify-metadata>true</verify-metadata>
flag enabled.@laurentsimon What about the score calculation? How should this affect the score?
IIUC, the gradle.properties
file will contain the text above. We currently don't support gradle in Pinning-Dependencies
check: how about we add it there and consider metadata checksum verification as hash pinning/lock file? In this case, a score of 10
would be fine. wdut?
Are there any other subtleties we need to be aware of? For example, for Npm, https://github.com/ossf/scorecard/issues/1174 was a surprise to me.
This issue is stale because it has been open for 60 days with no activity.
Discussed in 5/16 meeting: No gradle experts on the call, would require research, potentially out-of-scope for the project (but nice to have)
Dependency verification, as implemented by Gradle for example, allows verifying both checksums and signatures of dependencies actually used in a build. It is, IMHO, significantly more important than using an automated dependency upgrade tool, in comparison.
It would be great if this was actually considered in the score, since we strongly encourage users to enable dependency verification as a tool to reduce the risks of supply chain attacks.