Release provenance and signature verification for Notation v1.3.2 Windows AMD64

[riyadrashed-ai]

Hello Notary Project maintainers,

We are assessing whether the published Notation v1.3.2 Windows AMD64 tool can be admitted into a controlled, offline software supply-chain verification environment. We have deliberately not executed this candidate while its release publisher identity remains unverified.

Our existing static, same-channel download records identify:

• notation_1.3.2_windows_amd64.zip — SHA-256 014f25a530eee17520c8e1eb7380e4bd02ff6fc04479a07a890954e3b7ddfdc7
• notation_1.3.2_checksums.txt — SHA-256 71aada7225fb4284ed5cf3acb78c386c4ef883e1ea77bb0e4b17f83684dc592c
• notation.exe inside the archive — SHA-256 bc1de58a6c76671a9e7382b267c37b9faad28dac37185cd76f5509e74470a43b

We appreciate that matching the checksum distributed with the same release does not independently authenticate the publisher. Could you please clarify:

1. Whether these exact v1.3.2 release assets are covered by a cryptographically signed release attestation, signature, signed manifest or other publisher-controlled provenance record. If yes, where can we obtain the exact immutable signed statement or verification bundle, including its subject digest?
2. The formally authorized signing identity, certificate issuer or public-key trust root, and how an independent verifier should authenticate that identity without assuming that an unverified download is trusted merely because it came from the same release page.
3. The documented offline-verification procedure and expected signer/repository/workflow identity constraints (if applicable), together with any time, expiration, key-rotation and revocation caveats.
4. Whether the authentication applies to the ZIP itself, a checksum manifest, or the embedded executable; and how the corresponding byte-level subject should be compared.
5. If the v1.3.2 Windows AMD64 release was not publisher-signed or attested, can you confirm that and identify the project's recommended independently verifiable distribution or build-provenance route?

We are requesting public provenance metadata only, not private keys, user data, access tokens, or privileged infrastructure. We will separately assess the verification tool and its sandbox before running any untrusted executable.

Thank you for clarifying the available release integrity and publisher-authentication evidence.

[zuhairhalawa]

The v1.3.2 release carries no signature or attestation for its assets, so the checksum file is the only integrity metadata it ships. At that tag, release-github.yml (triggered by v* tags, runs GoReleaser) has no signing, SBOM or attestation step and no id-token permission, and .goreleaser.yml has no signs or sboms section. The release assets are the six archives plus notation_1.3.2_checksums.txt, with no .sig, certificate or bundle files. GitHub's attestations API returns 404 for the Windows ZIP's SHA-256, and the install docs only describe comparing a checksum. So there is no signing identity, trust root or revocation process to verify against for these assets.

Your hashes line up with the published manifest: notation_1.3.2_checksums.txt lists 014f25a530ee...ddfdc7 for notation_1.3.2_windows_amd64.zip, and the checksums file itself hashes to 71aada7225fb...dc592c. As you note, that only shows the download matches what the release page serves, not who published it.

The anchor you can check is the tag: v1.3.2 points at commit 001cc919603c1dc16c6aad387c94b4209cb9c901 ("bump: release v1.3.2"), which GitHub reports as validly signed. If that is not enough for your environment, the alternative is to build from that tag yourself instead of using the prebuilt ZIP.

[zuhairhalawa]

If this covers what you needed for your assessment, could you mark the answer as accepted so it is easy for others to find?