Unpacking lockfiles in different package managers

[Yogya Gamage]

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 <john at status6.com>
Sent: Monday, December 8, 2025 2:12 PM
To: Reproducible Builds List <rb-general at lists.reproducible-builds.org>
Cc: Deepika Tiwari <deepika.tiwari at systemverification.com>; Martin Monperrus <monperrus at kth.se>; Yogya Gamage <yogya.gamage at umontreal.ca>; Benoit Baudry <benoit.baudry at umontreal.ca>
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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20251210/a8583a1d/attachment.htm>