Thanks, John, for sharing the comments and the nice blog post. Just to clarify, we are not stating that Gradle or Maven lack a checksum feature. Rather, we are saying that within the lockfile feature, checksums are not included, whereas many other package managers do include them. As a result, when a developer creates a lockfile and uses lockfile-related features, they do not benefit from the checksum functionality. They would need to rely on other mechanisms to generate checksums, which is also outside the scope of the paper.
Regarding the second comment, even though the majority of developers use specific versions, version ranges are still allowed and occasionally used. Therefore, even if a developer believes they are specifying all versions explicitly, there may still be transitive dependencies that include ranges, which results in nondeterminism. Beyond that, as we discussed in the paper, there are additional benefits of lockfiles, such as allowing code review of transitive dependency changes and supporting debugging, among others. It is our opinion, based on our study, that had Gradle/Maven made the lockfile feature a default and more user-friendly, developers may have used them more. Best, Yogya ________________________________ From: John Neffenger <[email protected]> Sent: Monday, December 8, 2025 2:12 PM To: Reproducible Builds List <[email protected]> Cc: Deepika Tiwari <[email protected]>; Martin Monperrus <[email protected]>; Yogya Gamage <[email protected]>; Benoit Baudry <[email protected]> Subject: Re: Unpacking lockfiles in different package managers AVIS: Courriel externe. Soyez vigilant. On 12/5/25 5:17 AM, Benoit Baudry wrote: > Shall this ring a bell don't hesitate to reach out The paper prompted a discussion on the Maven Developer List and a good article by the Maven Trusted Checksums author, Tamás Cservenák: Lockfiles https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaveniverse.eu%2Fblog%2F2025%2F12%2F06%2Flockfiles%2F&data=05%7C02%7Cyogya.gamage%40umontreal.ca%7Cb8025445a4644677322a08de368dc52a%7Cd27eefec2a474be7981e0f8977fa31d8%7C1%7C0%7C639008179685874755%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DRBwhB%2BBZO6bHdmrjASdSIPvvGPvUTnIe7gFKxxv6x0%3D&reserved=0<https://maveniverse.eu/blog/2025/12/06/lockfiles/> Thanks for starting the conversation! Now that I've read the paper, I have two comments regarding its "Recommendations for package manager developers." 1. Recommendation #4 says, "At the other extreme, Gradle presents a serious lockfile anti-pattern by omitting essential details such as checksums." Yet Gradle *does* have checksums for dependency verification. Here is the checksum file that we use in the JavaFX project: openjdk - jfx/gradle/verification-metadata.xml https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fmaster%2Fgradle%2Fverification-metadata.xml&data=05%7C02%7Cyogya.gamage%40umontreal.ca%7Cb8025445a4644677322a08de368dc52a%7Cd27eefec2a474be7981e0f8977fa31d8%7C1%7C0%7C639008179685911277%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UastLjbQoPsHsc3eeG75OQW3wNtA%2BPO1PCrbPx5i3lY%3D&reserved=0<https://github.com/openjdk/jfx/blob/master/gradle/verification-metadata.xml> The Gradle developers considered the locking of versions and the verification of dependencies to be "orthogonal" [1], so they implemented them separately. But the checksum feature is present, as it is for Maven. 2. Recommendation #5 says, "On the other end, when the lockfile is not generated by default, as with Gradle, developers seldom use them." Rather than because of Gradle defaults, in my experience, Java developers don't use lockfiles because they don't use ambiguous versions for their dependencies in the first place. They specify exact versions in the build file ('build.gradle' or 'pom.xml'), so the build file itself is essentially the lockfile. Then, for security reasons, they add dependency verification using the checksum features of Gradle or Maven. Tamás discusses this further in his blog post linked at the top, including the pitfalls of doing this only through "best practices." John [1]: https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgradle%2Fgradle%2Fissues%2F5633%23issuecomment-395323940&data=05%7C02%7Cyogya.gamage%40umontreal.ca%7Cb8025445a4644677322a08de368dc52a%7Cd27eefec2a474be7981e0f8977fa31d8%7C1%7C0%7C639008179685941496%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5K6CNtYJ7YOwTFD0eF22Mj7im3OMx0VyJ1wmklexVq0%3D&reserved=0<https://github.com/gradle/gradle/issues/5633#issuecomment-395323940>
