Skip to content

feat(distribution): verify the released Windows binary and add a Scoop manifest - #413

Open
juyterman1000 wants to merge 1 commit into
mainfrom
feat/issue-279-scoop-evidence-and-drafts
Open

feat(distribution): verify the released Windows binary and add a Scoop manifest#413
juyterman1000 wants to merge 1 commit into
mainfrom
feat/issue-279-scoop-evidence-and-drafts

Conversation

@juyterman1000

Copy link
Copy Markdown
Owner

Refs #279 (Phase 4 — maintained package channels).

The Scoop Main entry was blocked on "Publish and verify a stable Windows CLI artifact before submitting a Scoop manifest." The artifact already exists — entroly-rs-x86_64-pc-windows-msvc.zip on release entroly-v1.0.81 — but nothing recorded whether it works, so the blocker could not be retired on evidence.

Verified against the published asset (not a local build)

Windows 11, x86_64:

Check Result
sha256 vs published sidecar d7d0a92e…97894match
archive contents one self-contained entroly-rs.exe, no installer
--version entroly-rs 1.0.81 — matches release tag and repo
compress --budget 120 7,786 bytes → 445, exit code 0

Output was well-formed source, not a truncation artifact. The binary needs no Python runtime, which is what makes it a legitimate Scoop candidate rather than a pip wrapper.

Added

  • packaging/scoop/entroly.json — pinned to the verified URL and hash, bin: entroly-rs.exe, checkver on this project's entroly-v<version> tag format, autoupdate resolving the hash from $url.sha256.
  • docs/distribution/windows-artifact-verification.md — the commands and raw output, so the claim is reproducible instead of asserted. Includes the silent-install contract (extract-and-run, no elevation, no PATH mutation, uninstall = remove the directory).

Status stays blocked — deliberately

The published .sha256 sidecar names the file as:

d7d0a92e…97894 *dist/entroly-rs-x86_64-pc-windows-msvc.zip

Scoop matches a hash line against the basename, so the dist/ prefix may defeat extraction and force a fallback. Scoop is not installed on the verification host, so this was not exercised — and scoop install end-to-end was not run for the same reason.

next_action now names that narrower blocker instead of the one that is satisfied. Marking this prepared would assert a readiness the evidence does not support, and would also fail the surface check, which requires every required_assets entry of a prepared target to exist as a file.

Resolution is one of: confirm Scoop's fallback tolerates the prefix, or publish the sidecar with a bare basename.

Verification

check_distribution_surface.py and check_external_name_policy.py both pass. Distribution tests: 22 passed. The single failure in the local run is a pre-existing one caused by an untracked working-tree file (marketing/launch/new_targets_strategy.md) that is not part of this branch and does not exist in CI.

targets.json was edited surgically (2 insertions, 2 deletions) to preserve the file's inline-array formatting — a json.dumps round-trip reflowed 168 lines and was reverted.

…p manifest

The Scoop Main entry was blocked on "publish and verify a stable Windows CLI
artifact". The artifact exists — `entroly-rs-x86_64-pc-windows-msvc.zip` on
release entroly-v1.0.81 — but nothing recorded whether it actually works, so
the blocker could not be retired on evidence.

Verified on Windows 11 against the published asset, not a local build:

- sha256 recomputes to d7d0a92e…97894, matching the published sidecar;
- the archive holds one self-contained entroly-rs.exe, no installer;
- `--version` reports 1.0.81, matching the release tag and the repo;
- `compress --budget 120` reduced 7,786 bytes to 445 with exit code 0.

Adds `packaging/scoop/entroly.json` pinned to that URL and hash, with checkver
on this project's `entroly-v<version>` tag format, and
`docs/distribution/windows-artifact-verification.md` recording the commands and
raw output so the claim is reproducible rather than asserted.

Status stays `blocked`, deliberately. The published .sha256 sidecar names the
file as `*dist/<archive>` while Scoop matches the basename, so autoupdate hash
extraction may fall back — and Scoop is not installed on the verification host,
so it was not exercised. `next_action` now names that narrower blocker instead
of the one that is satisfied. Marking this `prepared` would assert a
readiness the evidence does not support.

Refs #279 (Phase 4).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant