RUM-3100 generate checksum xml#2695
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #2695 +/- ##
===========================================
- Coverage 70.07% 69.98% -0.09%
===========================================
Files 822 822
Lines 30693 30693
Branches 5170 5170
===========================================
- Hits 21508 21479 -29
- Misses 7755 7770 +15
- Partials 1430 1444 +14 🚀 New features to boost your workflow:
|
| # This product includes software developed at Datadog (https://www.datadoghq.com/). | ||
| # Copyright 2019-Present Datadog, Inc | ||
|
|
||
| import sys |
There was a problem hiding this comment.
Great job !!
I am wondering where is this merger going to be used ? I am not seeing it yet in the code, is that correct ?
There was a problem hiding this comment.
It's used in a new Gitlab job
mariusc83
left a comment
mariusc83
left a comment
There was a problem hiding this comment.
I am thinking, should we add also some docs on how this should be verified on their end ? how should they use this xml ?
| - !reference [.snippets, set-publishing-credentials] | ||
| - ./gradlew :integrations:dd-sdk-android-glide:publishToSonatype --stacktrace --no-daemon | ||
| - ./gradlew :features:dd-sdk-android-rum:publishToSonatype --stacktrace --no-daemon | ||
| artifacts: |
There was a problem hiding this comment.
This will extract the generated XML for each module (as each one is published to Maven in its own job) so that it can be merged later in the new job.
| - publish:release-okhttp | ||
| - publish:release-okhttp-otel | ||
| - publish:release-benchmark | ||
| script: |
There was a problem hiding this comment.
ok I see the script is being used here, I wonder what's the purpose of this merged file ?
There was a problem hiding this comment.
The purpose is to have a single XML file to provide our customers with all sha256 there.
I thought about publishing all the individual xml files, but that would be a hassle, compared to just copy-pasting the content of a single file in their own verification-metadata.xml. Even if they have hashes for unnecessary libs, it'll still work.
0xnm
left a comment
0xnm
left a comment
There was a problem hiding this comment.
lgtm! nice job.
I left some comments, but nothing blocking.
| when: on_success | ||
| expire_in: 7 days | ||
| paths: | ||
| - dd-sdk-android-internal/verification-metadata.xml |
There was a problem hiding this comment.
probably it should be tools/dd-sdk-android-benchmark-internal/verification-metadata.xml here?
anyway, we can skip metadata publication here, because this one is only consumed by our internal apps and we don't want to enable verification there, we don't need it.
| xmlns = NS_DEPS_VERIF | ||
| TAG_CONFIGURATION { | ||
| TAG_VERIF_METADATA { -true.toString() } | ||
| TAG_VERIF_SIGNATURE { -false.toString() } // TODO-RUM-3104 add signature verification |
There was a problem hiding this comment.
| TAG_VERIF_SIGNATURE { -false.toString() } // TODO-RUM-3104 add signature verification | |
| TAG_VERIF_SIGNATURE { -false.toString() } // TODO RUM-3104 add signature verification |
| import java.io.File | ||
| import java.security.MessageDigest | ||
|
|
||
| open class GenerateVerificationXmlTask : DefaultTask() { |
There was a problem hiding this comment.
so it seems there is no Gradle built-in way to generate it? It seems that one can use https://github.com/sigstore/sigstore-java, but indeed it may be simpler to generate it manually.
There was a problem hiding this comment.
Gradle can only generate it for the depdencies your project is using but not for a library you're publishing (I couldn't find any doc for library maintainers at all), so for now I think it's better to do it manually.
I did check that the sha256 computed here matches the one when we publish to Maven (checked with publishToMavenLocal)
| import java.io.File | ||
| import java.security.MessageDigest | ||
|
|
||
| open class GenerateVerificationXmlTask : DefaultTask() { |
There was a problem hiding this comment.
should we have a test/validation that generated XML indeed matches the schema?
There was a problem hiding this comment.
That's a good point, I'll try and see if I can write a test for that 👍
I'll add a doc in confluence on the process, the idea is to have the doc published in our release notes on github. |
75b942f
0b289ea to
75b942f
Compare
5 participants
What does this PR do?
Gradle allows developers to add a
verification-metadata.xmlfile to their project to pin dependencies with a specific hash or PGP signature. This prevents attack if the artifact repository is compromised.Note
When publishing an artifact to Maven, the hash is automatically computed, and downloaded by Gradle with the artifact itself. If the
verification-metadata.xmlis present, it will compare the downloaded hash with the one in the xml file and abort the build if they don't match.In order to improve our customer's trust in our artifact, this PR will generate a
verification-metadata.xmlfile for each published artifact (as part of thepublish:<module>job), and a new job will create a mergedverification-metadata.xmlthat we can publish on GitHub and customers can refer to to ensure at any given time that the hash present in Maven is the expected one.