Windows build provenance attestation and the --signer-repo requirement

Scope

This guide covers verifying a GitHub build provenance attestation for a Windows artifact that a reusable workflow built, using gh attestation verify. It explains the --signer-repo requirement and the misleading issuer "sigstore.dev" error you get without it. It does not cover Authenticode signing, malware classification, or SmartScreen, which the Windows release evidence guide separates.

What the attestation proves

A build provenance attestation is a statement, signed by GitHub through Sigstore, that a named workflow built a specific file from a named public source on GitHub’s runners. Verifying it confirms the downloaded bytes came out of that pipeline. It does not confirm the file is safe to run, that a named company stands behind it, or that Windows will trust it on first launch.

The –signer-repo requirement

When a repository builds its own release, the attestation’s signing identity is that same repository, and gh attestation verify FILE --repo OWNER/NAME is enough.

JDE Projects builds differently. The signing happens inside a reusable workflow that lives in one shared repository, Build-Tools, while each app has its own repository. The attestation is signed by the Build-Tools workflow, not by the app repository. So the check has to name both: --repo for the app the file belongs to, and --signer-repo for the repository whose workflow did the signing.

Leave --signer-repo off and the check fails with a message built around issuer "sigstore.dev". It reads like the attestation is bad. It is not. The --signer-repo flag, in GitHub’s own words, exists to “enforce that the workflow that signed the attestation’s repository matches the provided value.” Without that value, the check has nothing to match the shared workflow’s identity against, and it refuses the attestation instead of accepting a signer it was not told to expect.

How to verify

Run the check with both repositories named. For the portable ZIP:

gh attestation verify YourAppName-v1.0.0.zip \
  --repo JDE-Projects/YourAppName \
  --signer-repo JDE-Projects/Build-Tools

The installer is the same command with the -setup.exe file:

gh attestation verify YourAppName-v1.0.0-setup.exe \
  --repo JDE-Projects/YourAppName \
  --signer-repo JDE-Projects/Build-Tools

A Verification succeeded! line means the file was built by this pipeline from the named public source. That is the whole claim.

Production evidence

The Build-Tools release workflow signs the ZIP and installer as a reusable workflow, which is why the signer is Build-Tools and not the calling app. The Build-Tools README records the exact --signer-repo value and the issuer "sigstore.dev" failure.

Unsupported or external outcomes

• A passing attestation is not an Authenticode signature and does not change what SmartScreen shows on first run.
• It does not classify the file as safe or malicious.
• It says nothing about a commercial identity or publisher reputation.
• The check depends on the source repository and its workflow staying public. A private or deleted source repository changes what can be verified.

Related guides

• Release route hub
• Windows release evidence: hashes, provenance, and signing

Source ledger