[
https://issues.apache.org/jira/browse/SOLR-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18034824#comment-18034824
]
Piotr Karwasz commented on SOLR-17657:
--------------------------------------
Hi [~malliaridis],
I’ve tested the migration to native *Gradle Verification Metadata* and opened
[PR #3828|https://github.com/apache/solr/pull/3828].
The migration itself was straightforward, but it raises an important question
about *how to maintain the metadata during dependency upgrades*.
As far as I can tell, the checksums currently in {{solr/licenses}} are used to
provide *integrity* but not *authenticity*. If that’s correct, one option would
be to add {{--write-verification-metadata sha256}} to the Renovatebot cleanup
tasks, so that Renovate automatically regenerates checksums for new or updated
dependencies during its first run.
Alternatively, we could enable *PGP signature verification*. This is, however,
an *all-or-nothing* mechanism: it would only slightly increase supply-chain
security by ensuring that builds fail whenever a PGP key changes, prompting
manual key validation. In this setup, {{--write-verification-metadata sha256}}
would no longer be needed as long as artifacts are signed.
As far as I remember, Maven Central requires signatures for new artifacts,
though PGP keys aren’t always easily retrievable. This means that some
dependency upgrades might still require manual intervention to fetch missing
keys or fall back to checksums.
In my experiments, roughly *100 missing keys* were detected, which, considering
the size of Solr’s dependency stack (including the build system), is a
manageable number.
> Evaluate and Update checksum and signature verification
> -------------------------------------------------------
>
> Key: SOLR-17657
> URL: https://issues.apache.org/jira/browse/SOLR-17657
> Project: Solr
> Issue Type: Improvement
> Components: Gradle
> Reporter: Christos Malliaridis
> Priority: Major
> Labels: checksum, gradle, integrity, pull-request-available,
> verification
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Dependency verification is an important step that is used when we want to
> verify the integrity of third-party libraries. Right now, we have custom
> gradle tasks for generating and verifying the gradle checksums.
> These custom gradle tasks seem to be limited in their dependency resolution
> and do not check dependencies from plugins, buildSrc or integrated builds.
> Gradle comes with dependency verification options that also support signature
> checks, whereever available. It is also capable of taking plugins and
> configurations from buildSrc and integrated builds into account. See [Gradle
> dependency
> verification|https://docs.gradle.org/current/userguide/dependency_verification.html]
> for more information.
> h2. Task
> Evaluate the output and the capabilities available of the Gradle-native
> features from the above link and update the gradle tasks and development
> flows if they are preferred.
> You can use the gradle task
> {{.\gradlew \-\-write-verification-metadata sha256 help}}
> for generating your first output at {{gradle/verification-metadata.xml}}.
> h2. Acceptance Criteria
> - The GitHub workflows continue verifying checksums and optionally signatures
> If updated to the Gradle-native tasks:
> - The steps in our developer guide are updated accordingly
> - redundant custom gradle tasks related to the checksum generation and
> verification are removed
> - Checksum files from {{solr/licenses}} are removed
> If not upated to Gradle-native tasks:
> - The existing tasks are updated so that checksums from the new UI module
> (Kotlin multiplatform module) are also generated
> h2. Additional Information
> The new UI module introduced in #2605 is a Kotlin multiplatform module, which
> does not use the JavaPlugin that is used for resolving jar information (see
> jarValidation task). This means that it is not covered by our custom tasks.
> We should try to address this issue before Solr 10 is released, because we
> have already changed a lot of things related to dependency management.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
