Repository navigation
Conversation
bun audit reported 10 advisories (6 high), among them: - hono < 4.13.7: unescaped strings in hono/jsx boundary components (GHSA-hxh3-vqpv-xpqv). This backend does not render JSX, but the pinned version still carried the advisory. - ws < 8.20.1 through viem > isows: memory disclosure and fragment DoS (GHSA-58qx-3vcg-4xpx, GHSA-96hv-2xvq-fx4p). - braces, flatted, fflate, picomatch: dev-only, mostly through the unused @vitest/ui. Runtime: hono 4.13.13, @hono/zod-validator 0.9.1, viem 2.57.5. zod stays on 3.25.76, which carries no advisory; moving to zod 4 is a separate API change. Dev: drop @vitest/ui and openapi-types, which nothing imports; vitest 5.0.4, oxlint 1.88.0, typescript 5.9.3, @types/bun 1.4.2. Override source-map-js to 1.2.2 (GHSA-68fv-2mgg-jv7q via vite). bun audit is now clean. oxlint 1.x rejects the 0.9 config format, so .oxlintrc.json moves to `plugins` and `ignorePatterns`, and the two catch clauses that never read their error drop the binding. Signed-off-by: Leechael Yim <yanleech@gmail.com>
dstack-kms 0.6 posts `dstack_verifier::PolicyBootInfo` to the webhook: unprefixed hex bytes plus `teeVariant` and `keyProviderInfo`, which the contract does not take. The existing tests only used 0x-prefixed payloads without those fields. The new tests post that exact shape to both routes and assert every policy field reaches isKmsAllowed/isAppAllowed padded and prefixed, an empty instanceId becomes the zero address, and a non-UpToDate TCB status is passed through for the contract to judge. Making the schema strict fails all four. Signed-off-by: Leechael Yim <yanleech@gmail.com>
The bootAuth routes buffered and parsed any body before validation rejected it: a 50 MB JSON body was accepted (200) and grew the process to ~187 MB RSS. Anyone who can reach the port could repeat that. Cap /bootAuth/* at 128 KiB and answer 413 with the usual invalid request body. A valid BootInfo stays far below that; the schema's own bounds peak around 32 KiB of advisoryIds. Add hono's secureHeaders so responses carry nosniff and SAMEORIGIN framing. Every response is JSON or a fixed text/plain 404, so there is no reflected content to exploit; the headers are defense in depth for a browser that reaches the port. The tests also pin the existing CSRF posture: a cross-origin text/plain or form POST is rejected with 400 before any contract read, and no CORS header is ever sent. There are no cookies or state-changing routes, so no token is needed. Signed-off-by: Leechael Yim <yanleech@gmail.com>
The deployed auth-api image was built by hand from a Dockerfile that cloned a fixed commit at build time, on oven/bun:1.2.18. Build from the checked-out directory instead, so the image carries exactly the source and lockfile under review. - base oven/bun:1.4.2-alpine, pinned by digest - production dependencies only, installed from the frozen lockfile with lifecycle scripts disabled - runs as the image's unprivileged `bun` user - PORT defaults to 8000, matching the KMS webhook default http://auth-api:8000; NODE_ENV=production - .dockerignore admits only package.json, bun.lock and index.ts Signed-off-by: Leechael Yim <yanleech@gmail.com>
There was no CI build of the auth webhook image; deployments pinned a hand-pushed Docker Hub image. Add a workflow independent of the KMS release: - pull requests and pushes touching dstack/kms/auth-eth-bun run bun audit, lint and tests, then build the image without pushing - a `kms-auth-eth-bun-v<version>` tag (or a manual run naming an existing one) publishes ghcr.io/dstack-tee/dstack-kms-auth-eth-bun:<version>, checks anonymous pull access, attaches build provenance and writes the digest-pinned reference to the job summary Actions are pinned by commit, checkouts do not persist credentials and setup-bun runs without its cache, per zizmor. The README documents the image and how to deploy it by digest. Signed-off-by: Leechael Yim <yanleech@gmail.com>
This branch has not been deployed
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
1 participant
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.
Problem
The auth-eth-bun webhook that production KMS instances run is still the image built in July 2025 (commit ca4af02, bun 1.2.18). It has no CI build: the image was pushed by hand to a personal Docker Hub namespace, so nobody can reproduce or verify it. Its dependencies are a year old. The server also buffers a request body of any size before validation rejects it: a 50 MB POST to
/bootAuth/appwas accepted and parsed in full.Before rolling KMS 0.6.x, we also need to confirm that the webhook still accepts the 0.6
bootAuthpayload.Fix
e04779cb): hono 4.13.13, @hono/zod-validator 0.9.1, viem 2.57.5. Dev tooling: vitest 5, oxlint 1.88 (.oxlintrc.jsonmigrated to the v1 format), TypeScript 5.9. Removed the unused@vitest/uiandopenapi-types. Pinnedsource-map-jswith an override.bun auditis clean.9ac486f0): KMS 0.6 sendsPolicyBootInfohex fields without the0xprefix and addsteeVariant/keyProviderInfo. The zod schema already accepts unprefixed hex and strips unknown fields, so no code change was needed. New tests pin the exact payload shape so a later schema change cannot break it silently. The README documents the 0.6 operator steps: register the newosImageHashand KMSmrAggregated;enforce_self_authorizationnow defaults to true.0e711aa6): a 128 KiBbodyLimiton/bootAuth/*returns 413 with the usual denial body. A valid BootInfo is capped by the schema far below that. HonosecureHeadersis applied to every response. Responses are JSON only, so CSRF and XSS do not apply, but the headers stop a browser from sniffing or framing one.107b45da):oven/bun:1.4.2-alpine, pinned by digest. It installs production dependencies only, runs as the non-rootbunuser, and listens onPORT=8000. The.dockerignoreis an allowlist.9f1c3dcc): a standalone workflow,kms-auth-eth-bun.yml. PRs and pushes run audit, lint and test, then build the image without pushing it. Akms-auth-eth-bun-v*tag (or a manual rerun of an existing tag) pushesghcr.io/dstack-tee/dstack-kms-auth-eth-bun:<version>, verifies anonymous pull and attaches build provenance. zizmor and actionlint are clean.Validation
bun run lintandbun run test:run: 31 tests pass. The body-limit tests were mutation-checked: they fail with the limit removed.0x2f83…26Ba9C):GET /returned the gateway app ID and app implementation, and a/bootAuth/kmscall with a 0.6-shaped payload returned a contract denial (OS image is not allowed), not a validation error.reuse lintpasses.imagejob is its first build.