<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Thanks, John, for sharing the comments and the nice blog post.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
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.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
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.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Best,</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Yogya</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> John Neffenger <john@status6.com><br>
<b>Sent:</b> Monday, December 8, 2025 2:12 PM<br>
<b>To:</b> Reproducible Builds List <rb-general@lists.reproducible-builds.org><br>
<b>Cc:</b> Deepika Tiwari <deepika.tiwari@systemverification.com>; Martin Monperrus <monperrus@kth.se>; Yogya Gamage <yogya.gamage@umontreal.ca>; Benoit Baudry <benoit.baudry@umontreal.ca><br>
<b>Subject:</b> Re: Unpacking lockfiles in different package managers</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">AVIS: Courriel externe. Soyez vigilant.<br>
<br>
<br>
On 12/5/25 5:17 AM, Benoit Baudry wrote:<br>
> Shall this ring a bell don't hesitate to reach out<br>
<br>
The paper prompted a discussion on the Maven Developer List and a good<br>
article by the Maven Trusted Checksums author, Tamás Cservenák:<br>
<br>
Lockfiles<br>
<a href="https://maveniverse.eu/blog/2025/12/06/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</a><br>
<br>
Thanks for starting the conversation!<br>
<br>
Now that I've read the paper, I have two comments regarding its<br>
"Recommendations for package manager developers."<br>
<br>
1. Recommendation #4 says, "At the other extreme, Gradle presents a<br>
serious lockfile anti-pattern by omitting essential details such as<br>
checksums."<br>
<br>
Yet Gradle *does* have checksums for dependency verification. Here is<br>
the checksum file that we use in the JavaFX project:<br>
<br>
openjdk - jfx/gradle/verification-metadata.xml<br>
<a href="https://github.com/openjdk/jfx/blob/master/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</a><br>
<br>
The Gradle developers considered the locking of versions and the<br>
verification of dependencies to be "orthogonal" [1], so they implemented<br>
them separately. But the checksum feature is present, as it is for Maven.<br>
<br>
2. Recommendation #5 says, "On the other end, when the lockfile is not<br>
generated by default, as with Gradle, developers seldom use them."<br>
<br>
Rather than because of Gradle defaults, in my experience, Java<br>
developers don't use lockfiles because they don't use ambiguous versions<br>
for their dependencies in the first place. They specify exact versions<br>
in the build file ('build.gradle' or 'pom.xml'), so the build file<br>
itself is essentially the lockfile. Then, for security reasons, they add<br>
dependency verification using the checksum features of Gradle or Maven.<br>
<br>
Tamás discusses this further in his blog post linked at the top,<br>
including the pitfalls of doing this only through "best practices."<br>
<br>
John<br>
<br>
[1]: <a href="https://github.com/gradle/gradle/issues/5633#issuecomment-395323940">
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</a><br>
<br>
</div>
</span></font></div>
</body>
</html>