feat: add registry artifact integrity check - #1091
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new GitHub Actions “integrity canary” to detect cases where registry.coder.com might be serving tarballs from a non-registry origin by asserting the presence of the Server-Version header on sampled /download/ responses.
Changes:
- Introduces a scheduled workflow (
check-registry-integrity) that runs every 15 minutes (offset from the existing health check) and executes a new integrity-check script. - Adds a bash script that discovers modules via the registry API, samples a rotating window, and verifies the
Server-Versionheader on tarball HEAD responses (with cache-busting +Accept-Encoding: gzip).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/workflows/check_registry_integrity.yaml | Adds scheduled workflow to run the integrity canary script. |
| .github/scripts/check_registry_integrity.sh | Implements module discovery + sampled tarball header verification and triage-oriented failure output. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
@DevelopmentCats this is kind of easy to bypass if they just decide to mimick it, or if they serve the same thing as us except the binaries, can we also make this check if the served module corresponds to its GH counterpart? e.g for Mux, So you'd check that |
|
^ feel free to say no and we'll do it later too |
No I think you are actually right on this @phorcys420 I was mostly just getting us to a starting point this so that if there was any byte difference in the modules it would be caught, but you have a valid point |
DevelopmentCats
changed the title
Adds a scheduled check that verifies module tarball responses from registry.coder.com originate from the registry application. Every response from the registry application sets a Server-Version header via serverVersionMiddleware, so a response without one did not come from the registry application. The check probes a rotating sample of tarball URLs and asserts the header is present. Kept separate from check-registry-site-health: that workflow reports availability to the public status page, whereas a failure here warrants engineering triage rather than an automatic public status update. This workflow has no Instatus credentials in scope. Scope is limited to verifying who answered the request, not what was served; content verification against release tags is not covered here.
a0c8d1b to
e2fa4b5
Compare
What
Adds a scheduled check that verifies responses for module tarballs from
registry.coder.comoriginate from the registry application itself.Draft — design is still being discussed internally. See notes below.
How
Every response from the registry application sets a
Server-Versionheader. The check probes a rotating sample of module tarball URLs and asserts the header is present.Implementation notes:
/download/, not the frontend pages the health check covers.Accept-Encoding: gzip, which the download handler requires.Why this is separate from
check-registry-site-healthThe two answer different questions. Health asks whether the registry is reachable and reports availability to the public status page. This asks whether responses are coming from the registry application, which warrants engineering triage rather than an automatic public status update.
This workflow has no Instatus credentials in scope and cannot open a public incident.
Known limitations
Status
Draft pending internal design review. Not ready for merge.
Test plan
Validated locally against production and against local origins with and without the header.
bun fmt:ciand shellcheck (at CI severity) pass.