The term "verification" is in the context of "Verifying Apache Software Foundation Releases" [1]. The tool however does more than verifying signatures and checksums.
Efforts for reproducible builds, trusted releases and release verification are somewhat related - in the sense of being able to verify that the release artifacts are exactly what one expects. I intentionally did not include any test runs, because that's what CI should have already done against the same Git commit. This is where reproducibility comes into play. Like, if I can see that CI against release commit ABCDEF is "green" and I can be certain that "my" built artifacts of the same commit are the same as the release candidate ones, I can be certain that the tests also pass for me. NB: The tool has a `--keep-temp-dir` option, which can be used to run tests against the downloaded code base and artifacts, so one doesn't need to download "all the things" again. [1] https://www.apache.org/info/verification.html On Fri, Oct 24, 2025 at 2:57 PM Alexandre Dutra <[email protected]> wrote: > > Hi Robert, > > Thanks for taking the initiative on this. Your tool will significantly > streamline our release verification tasks, and I've left a few minor > comments on your PR. > > I think we need to define "verification" more precisely here. It > appears your tool primarily focuses on reproducible builds and > verifying that staged artifacts match our expectations, rather than > "verification" in the sense of building and testing the distribution. > > If my understanding is correct, then running the verification tool as > a GitHub workflow is perfectly fine. > > We could also introduce another tool or script dedicated to building > and testing the produced artifacts (apologies if such tool exists > already). However, as Yufei pointed out, I'd rather have people > running this other tool locally to catch any environmental issues. > > Thanks, > Alex > > On Thu, Oct 23, 2025 at 8:30 PM Yufei Gu <[email protected]> wrote: > > > > Hi Robert, > > > > Thanks for working on this. I think it's valuable to have a script to > > verify RCs. I'm not sure whether a Github workflow helps. Verification > > tends to be more effective when done in each individual environment(Laptop, > > Cloud workspace, etc). That's how we spot more issues, esp. env-specific > > issues. > > > > > > Yufei > > > > > > On Thu, Oct 23, 2025 at 6:29 AM Robert Stupp <[email protected]> wrote: > > > > > Hi all, > > > > > > Verifying a Polaris release is a pretty manual process that involves a > > > lot of individual steps. > > > > > > As I am a lazy guy and like automation for the tasks that can be > > > automated, I built a bash script to perform a lot of the release > > > verification steps, like > > > * Git commit/tag cross-verification > > > * Build Polaris > > > * Build Helm Chart > > > * Verify GPG signatures > > > * Verify checksums > > > * Compare the binary artifacts > > > > > > Many of the verifications also apply to the Apache Trusted Releases > > > effort, in particular getting to reproducible builds. > > > > > > The tool can be run directly from a terminal (no download necessary) > > > and requires a few parameters (version, RC number, Git commit, Nexus > > > staging repo ID). Please note that the `bash/curl` command mentioned > > > on the new web page doesn't work yet as the PR is not merged yet. > > > > > > More detailed information is available in the PR, which also adds a > > > new page to the Polaris website on "how to verify a release". > > > > > > We could also create a GitHub workflow for the script, if that's > > > convenient for committers (aka those who can run GH workflows). > > > > > > PR: https://github.com/apache/polaris/pull/2824 > > > Direct link to the new website page: > > > > > > https://github.com/snazy/polaris/blob/release-verification/site/content/release-verify.md > > > > > > Robert > > >
