https://gradle.com/ logo
Join Slack
Powered by
I’m trying to migrate to dependency verification, ...
# dependency-management
v
I’m trying to migrate to dependency verification, and I find it hard to use 1. It has 
trusted-keys
and then it might have 
component/artifact/pgp
below. How do they differ?
Copy code
<trusted-key id="0D35D3F60078655126908E8AF3D1600878E85A3D" group="io.netty" name="netty-bom" version="4.1.104.Final"/>
Copy code
<component group="io.netty" name="netty-bom" version="4.1.101.Final">
         <artifact name="netty-bom-4.1.101.Final.pom">
            <pgp value="0D35D3F60078655126908E8AF3D1600878E85A3D"/>
         </artifact>
      </component>
What is the reason Gradle adds a component-related record while there’s 
trusted-key
for it? 2. It looks like 
trusted-key
and 
component
duplicate information. 3. The entries in 
trusted-key
are not consistent. Sometimes they include only group, sometimes they include component, and sometimes they include the version as well:
Copy code
<trusted-key id="187366A3FFE6BF8F94B9136A9987B20C8F6A3064" group="com.google.protobuf"/>
         <trusted-key id="190D5A957FF22273E601F7A7C92C5FEC70161C62" group="org.apache" name="apache" version="18"/>
         <trusted-key id="19BEAB2D799C020F17C69126B16698A4ADF4D638" group="org.checkerframework" name="checker-qual"/>
Frankly, I find it quite surprising. Should it rather be configured with a setting like “trust PGP for group/group+artifact/group+artifact+version”? 4. It is strange 
--write-verification-metadata
requires 
pgp,sha256
arguments. Should it rather be included into the 
verification-metadata.xml
? My understanding is that 
verification-metadata.xml
should be self-sufficient to specify what it actually verifies. Then 
--write-verificaiton-metadata
should be idempotent. I’m using Gradle 8.14.3 if that matters
t
Do they really duplicate information? If you have a <trusted-key> covering a component, then you shouldn't need a <component> for it (see Gradle's how verification-metadata.xml) But otherwise, yes, a bit hard to use.
v
They do duplicate the information. At least, they both relate to the same key id
At the same time, the documentation provides no clue on the meaning of those xml nodes
t
Yes, but trusted-key can match many components, whereas component/artifact/pgp is only for that specific artifact (if not already matched by a trusted-key or trusted-artifact)
v
That is exact duplication I mean. The default generator should lean towards a single style rather than producing entries with varying styles
👍 1
It is inconvenient that 
trusted-key
has no clear structure. Sometimes the entries are coded in attributes, sometimes 
trusting
are coded as children nodes. It is inconvenient that the list is ordered by key id rather than group name.
👍 1
t
Fwiw, my use case with verification metadata is only about ensuring the artifacts we downloaded on CI are the same that our customer will download and put to production (we push to their Git repo and they build on their CI), so we're only interested in the checksums, not the "provenance" (pgp). Our workflow is to delete the verification-metadata.xml file, run a full build with --write-verification-metadata, and then make sure to not commit the trusted-artifacts that would have been removed (we added trusted-artifacts for the sources, javadoc, and gradle distribution)
So your problem is more about the --write-verification-metadata output and the lack of documentation for the file format 😉 (I agree!)
v
Copy code
<component group="com.github.vlsi.stage-vote-release" name="com.github.vlsi.stage-vote-release.gradle.plugin" version="1.90">
   <artifact name="com.github.vlsi.stage-vote-release.gradle.plugin-1.90.pom">
      <sha256 value="37656ed0e5626bf87a0b5f59dab729becbf8dbe5dbf77a533145acf567163add" origin="Generated by Gradle" reason="Artifact is not signed"/>
   </artifact>
</component>
However, there’s a valid pgp signature: https://repo1.maven.org/maven2/com/github/vlsi/stage-vote-release/com.github.vlsi.stage-vote-release.gradle.plugin/1.90/
Open in Slack
PreviousNext
Powered by