Pin actions, vcpkg revisions, packaging tools, and downloaded binaries with checksum verification

[cursor]

Status: implemented on dev, one item blocked on credentials

Verified against origin/dev on 2026-08-09. .github/pins/packaging-tools.json (schema v1) exists and pins every downloaded packaging binary by SHA-256, with .github/pins/README.md documenting the update procedure.

Tool	Pin	Verified
appimagetool	asset 324406882 @ a6d71e2b…	yes
AppImage runtime	asset 456065460 @ 1cc49bcf…	yes
linuxdeployqt	asset 306987716 @ 974a8745…	yes
WiX 3.14.1	versioned release URL @ 6ac824e1…	yes
Windows SDK MakeAppx.exe	10.0.26100.0 @ 00fff202…	needs runner confirmation
Flatpak / flatpak-builder	1.14.6-1ubuntu0.1 / 1.4.2-1build2 on ubuntu-24.04	yes
dpkg	1.22.6ubuntu6.6 on ubuntu-24.04	yes
DigiCert KeyLocker	null	BLOCKED

Each third-party pin records upstream + upstreamCommit alongside the asset ID, so a pin can be audited back to its source tree rather than trusting a release name.

Remaining work

1. BLOCKED — DigiCert KeyLocker pin (needs an operator with DigiCert credentials)

digicertKeylocker.version, .url, and .sha256 are intentionally null. The WindowsInstall MSI signing step now hard-throws when SIGN_MSI == true and the pin block is empty, rather than silently downloading — the fail-loud behaviour this issue asked for.

The previous flow fetched one.digicert.com/.../Keylockertools-windows-x64.msi/download with the SM_API_KEY header. That URL is mutable and therefore unpinnable. Unblocking requires someone with a DigiCert account to:

• resolve the exact KeyLocker Tools version in use;
• record its concrete, versioned, immutable download URL (not the redirecting /download endpoint);
• compute and record the SHA-256;
• fill the digicertKeylocker block and confirm a signed MSI still builds.

This is the same credential dependency as #39 (procure the code-signing certificate). Sequence #39 first — there is no reason to pin the signing tool before the certificate that makes it useful.

2. Confirm MakeAppx.exe on a real runner

windowsSdk.makeAppxSha256 was captured on a local machine. A local SDK install and the windows-2022 runner image can ship different binaries for the same nominal SDK version.

• Validate the digest on the first Windows CI run; if it differs, pin the runner's value and note in .github/pins/README.md that this digest is runner-image-specific and must be rechecked when the image is bumped.

3. Land the branch

The implementation is on dev and, per the earlier note, was uncommitted at the time of writing.

• Confirm it is committed and merged rather than sitting in a dirty working tree.

Acceptance criteria

• Every downloaded packaging binary is verified against a recorded SHA-256 before use; a mismatch fails the job loudly.
• No packaging step downloads from a mutable or redirecting URL.
• GitHub Actions are pinned by commit SHA, not tag.
• The vcpkg baseline revision is pinned in vcpkg-configuration.json.
• SIGN_MSI=true with an empty digicertKeylocker block fails with an explicit diagnostic — never a silent unverified download.
• .github/pins/README.md states how to rotate each pin and which are runner-image-specific.

Verification

# Every non-null pin must carry a 64-hex digest.
jq -e '[paths(type=="object") as $p | getpath($p)
        | select(has("sha256") and .sha256 != null)
        | .sha256 | test("^[0-9a-f]{64}$")] | all' \
  .github/pins/packaging-tools.json

# No unpinned action references (expect no output).
grep -rnE "uses: .*@(v[0-9]|main|master)" .github/workflows/

Dependencies

• Procure Windows code-signing certificate and enable SIGN_MSI #39 — Windows code-signing certificate. Blocks the DigiCert pin; do that first.
• [R-010] Harden OCR sidecar supply-chain guidance (bundled only) #45 — OCR sidecar supply-chain guidance. Same pinning discipline applied to loupe-ocr/; keep the two consistent rather than inventing a second mechanism.
• [0.2.0] Complete packaging / OSS licensing checklist #46 — packaging / OSS licensing checklist.

---

Migration provenance (imported record)

Field	Value
Tracker ID	#25
Evidence	Not started as of 2026-07-19 on mberry/mic-155-160-tier2-corpus. Prior audit still holds: CI workflows pin loosely; LinuxInstall downloads continuous …
Due	2026-07-18
Created	2026-07-19

---

Labels: P1-high, needed, audit:partial-rescope, scope:m, area:infra, surface:packaging, chore, surface:ci-build
Source: mberrys/Frisket-pdf#83 (created 2026-08-06T19:11:23Z)

Alignment amendment — 2026-08-10

This issue remains open in 0.0.2 for two explicit gates:

• Verify the Windows SDK MakeAppx.exe digest on the hosted Windows runner and record any runner-image-specific value.
• Keep DigiCert KeyLocker blocked on Procure Windows code-signing certificate and enable SIGN_MSI #39. The blocked signing path must fail closed and must never become an exception that permits an unverified download.

Reverify the committed branch state and pin-rotation documentation on the exact release candidate. SBOM and artifact provenance are tracked separately by #263.

[mberrys]

Supply-chain pinning work is on dev (uncommitted), implementation complete pending review. One item is intentionally left for an operator with DigiCert credentials:

BLOCKED — DigiCert KeyLocker (digicertKeylocker)

• digicertKeylocker.version, .url, and .sha256 are intentionally null in .github/pins/packaging-tools.json.
• The WindowsInstall MSI signing step now refuses to run when SIGN_MSI == true and the pin block is empty (hard throw, not a silent download) — the fail-loud behaviour required by this issue.
• The previous flow downloaded one.digicert.com/.../Keylockertools-windows-x64.msi/download using the SM_API_KEY header — a mutable URL. The pinned URL must be a concrete, versioned release artifact.
• To unblock MSI signing, someone with a DigiCert account must resolve the exact KeyLocker Tools version, record its immutable download URL and SHA-256, and fill the digicertKeylocker block.

Also still to confirm on a live windows-2022 runner: the MakeAppx.exe SHA-256 (windowsSdk.makeAppxSha256 in the same pins file) was captured from a local machine and must be validated against the runner image on the first Windows CI run.