Repository navigation
Generate SHA-256 sidecars for release assets in CI - #159
Merged
Merged
Conversation
AutoUpdateService already verifies a downloaded asset against a "<asset>.sha256" sidecar when one is present, but release.yml never produced one, so verification always fell back to unverified. Hash every release artifact in CI and publish the sidecar alongside it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HavJeraG7CAM1KBEXLGaRz
Contributor
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
A codebase audit flagged that
AutoUpdateService(src/EDNexus.App/AutoUpdateService.cs:131-160,211-237) already does best-effort SHA-256 verification of a downloaded update against a<asset>.sha256sidecar when one exists in the release — but.github/workflows/release.ymlnever generated or published one, so the verification code had nothing to check against and always silently fell through to "no checksum".This is a small, targeted fix distinct from the full signing scheme in #104 (which is being deprioritized as a nice-to-have, not a milestone requirement — key rotation and CI-secret maintenance for that is a bigger lift). This just closes the gap so the checksum verification that's already written actually does something: integrity-only, not authenticity, but a real improvement over nothing.
Changes
.github/workflows/release.yml: after downloading build artifacts and before creating the GitHub release, hash every artifact file and write a<file>.sha256sidecar next to it (sha256sum | cut -d' ' -f1). The existingfiles: artifacts/**/*glob on the release step already picks these up as release assets.How it was verified
No
dotnet/CI runner available in this environment to execute the workflow end-to-end. Verified by inspection:AutoUpdateService's sidecar name matching (fileName + ".sha256", case-insensitive) matches the sidecar naming this step produces (same basename with.sha256appended).sumText.Trim().Split(...)[0]) accepts a bare hash on its own line, which is what this step writes.find ... ! -name '*.sha256'avoids re-hashing already-generated sidecars if the step were ever re-run.Not verified: an actual tagged release run through the real workflow (would need a real release to trigger).
Checklist
CommanderState/engine code touched🤖 Generated with Claude Code
https://claude.ai/code/session_01HavJeraG7CAM1KBEXLGaRz
Generated by Claude Code