Closed Vampire closed 11 months ago
Thank you!
FYI, there's a new syntax for getting the current project as a dependency: project()
.
Also, for Gradle updates, I prefer that we do it ourselves to be sure that malicious wrapper jar and scripts are not introduced. Here, it looks like the wrapper is different when generated from Gradle 8.1.1 even though I specified the version 7.6. I tried to look into the diff but didn't see anything alarming. If you know why we had different outcomes, I would be interested to learn more.
FYI, there's a new syntax for getting the current project as a dependency: project().
Yep, I know. At least in the meantime. :-) Might not have known back then or forgotten it.
Also, for Gradle updates, I prefer that we do it ourselves to be sure that malicious wrapper jar and scripts are not introduced.
Sure, I seldomly update other projects Gradle versions, but I wanted to test with using the project as included build. But for that, it needs to be compatible with the build including it. And as the project I tested it with was on 7.6 with the changed API for the test suites, I fixed it on-the-fly and thought I submit it too. :-)
Against malicious wrapper introduction, you should maybe add a GitHub action run that uses the gradle/wrapper-validation-action
which is for exactly that use-case, ensuring the wrapper jar has one of the officially released checksums. Malicious build logic you hopefully would find by reviewing the changes, but hopefully in nothing I send. :-)
Here, it looks like the wrapper is different when generated from Gradle 8.1.1 even though I specified the version 7.6. I tried to look into the diff but didn't see anything alarming. If you know why we had different outcomes, I would be interested to learn more.
The 4 wrapper file are generated from the Gradle version you use to generate the wrapper files.
So as you used 8.1.1 to regenerate the wrapper files to make sure I'm not evil, you generated that state as of 8.1.1.
The version you specify to the wrapper
task is only used in the content of gradle/wrapper/gradle-wrapper.properties
that defines which version of Gradle is used at runtime.
You can also for example calculate the sha256sum of the wrapper jar and search for it on https://gradle.org/release-checksums manually to see that my submitted wrapper jar was from 7.6 while yours is coming from 8.1 or 8.1.1.
Due to that you should practically always run the wrapper
task twice (when using the wrapper of the project), first to update the Gradle version in the wrapper file and then to update the actual wrapper files with the state of the new version. Otherwise you are always behind with the actual wrapper files, which usually is not problematic, but of course might miss new improvements or changes in the actual wrapper.
The wrapper GitHub action checks only the jar file, not the shell script, which is not really human readable given its length and the cryptic shell/bash syntax, that's why I haven't been eager to add this one that I knew about.
Thanks for all the info, TIL 😃
Subject says it all :-)