-
Notifications
You must be signed in to change notification settings - Fork 518
Update signing config, fix configuration-cache compatibility #3058
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update signing config, fix configuration-cache compatibility #3058
Conversation
2f43d90
to
b5fb3af
Compare
ktlint-cli/build.gradle.kts
Outdated
windowsBatchScriptSource.set(layout.projectDirectory.file("src/main/scripts/ktlint.bat")) | ||
outputDirectory.set(ktlintOutputRoot) | ||
|
||
finalizedBy("signShadowJarExecutable", "shadowJarExecutableChecksum") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the configuration-cache compatibility fix. Previously the build tried to sign ktlint executable file as a part of shadowJarExecutable
invocation, now it'll run after shadowJarExecutable
completes, after the executable file has actually been created
val outputDirectoryPath = | ||
layout.buildDirectory | ||
.dir("run") | ||
.archiveFile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shadowJar
exposes a named output, so I updated the code so it's used here as well rather than iterating over outputs
manually
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is the build failed because it tries to sign the artifacts (since the project version set to stable one), but it doesn't have access to singing keys given the PR is opened from a fork.
Looking at the commits in the PR #1952 it is clear that the change was initiated by @Goooler. At April 20, 2023 @shashachu reverted the signing, followed by the release of version 0.49.0 on April 21, 2023. So it looks like that during release of Having said that, we can argue about the value of having the md5 files being published. No one has complained about a regression since the md5 files are missing. Does any of you have an argument in favor, or against re-adding the md5 functionality? |
Artifacts available on Maven central have their own authenticity certification: signature, hash, so from my perspective those hashes are useful only for people downloading artifacts directly from github release page (does that include homebrew? I have close to zero knowledge how homebrew works 😬 ) At the same time nothing prevents an attacker to swap both executable and hash file (releases can be edited, new artifact files can be uploaded), so I don't know if the checksum comes with any safety guarantee 😅 tl;dr I don't think these extra checksums bring any value, especialy they are gone for >2 years 😅 |
Github release pahe publishes the SHA256 for this: Also in ktlint documentation it is explained how to verify the downloaded file.
Agree. @Goooler, @shashachu, what do you think? |
:TIL:, looks like relatively new feature? None of the previous releases had such metadata attached 👀 |
b5fb3af
to
af74d3a
Compare
by introducing separate signing task
Do not generate checksum for signature file
af74d3a
to
9ec1ec6
Compare
// Avoid setting empty strings as signing keys. This avoids breaking the build when PR is opened from a fork. | ||
// Also, due to https://github.com/gradle/gradle/issues/18477 signing tasks try to prematurely access the signatory. | ||
// This also improves error messages if something's misconfigured | ||
useInMemoryPgpKeys(signingKeyId, signingKey, signingPassword) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new task I added (signShadowJarExecutable
) gets created eagerly, tries to access the signatory and fails if the signing info contains empty string (not nulls)
As a workaround I'm proposing to configure the signing conditionally. This solves the misbehavior of the Sign task, but also should not fail PRs from froks created during release (the isRequired
property is not the only input that determines if the signing tasks should run - link)
The checksum calculating code has been removed in 9ec1ec6 ✅ |
I don't like this idea, I don't like #3047 too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding of this part of the build is increased a lot. I have a lot of naming things that might improve the code even more. Please have a look at the suggestions.
Thanks for clearing that up in #3078 🙏 |
Description
This PR introduces the following set of behavior changes:
shadowJarExecutable
task intosignShadowJarExecutable
to make it compatible with configuration cacheshadowJarExecutable
automatically runsshadowJarExecutableChecksum
so the user-facing behavior is the same.RunningshadowJarExecutable
will also generate md5 checksums (disabled by https://github.com/pinterest/ktlint/pull/1952/files#diff-10bb684577395d2b98c65f30064e347f353307c7c4956b0a147b26e3085f3bbfL88. 0.48.2 had checksums attached, 0.49.0 did not). Changes from this PR should make them appear again on the artifacts listI couldn't find any usages ofshadowJarExecutableChecksum
task, which directly addressed: Provide checksum file along with release #695 . Please let me know if checksums aren't meant to be published I'll then propose to remove all the checksum related code.--rerun
flag results in a deterministic behavior)Checklist
Before submitting the PR, please check following (checks which are not relevant may be ignored):
Closes #<xxx>
orFixes #<xxx>
(replace<xxx>
with issue number)Documentation is updated. See difference between snapshot and release documentation