rename: @askalf/canon → @askalf/truecopy (npm-publishable name)#28
Merged
Conversation
This was referenced Jul 10, 2026
askalf
added a commit
that referenced
this pull request
Jul 22, 2026
…frvp-7c67-39w9) Scorecard opened a high-severity Vulnerabilities alert (#28) minutes after #91 landed. The dependency is not new — `npm i -g` was installing the same tree before — but nothing in the repo described it, so nothing could see it. The lockfile that #91 added is what made it visible, which is the point of having one. The advisory (published 2026-07-21, hours before that merge) is a path traversal in @hono/node-server's serve-static, patched in 2.0.5. It reaches this image transitively: server-everything -> @modelcontextprotocol/sdk -> @hono/node-server "^1.19.9". That caret range can never resolve to 2.0.5, the SDK is already at its latest (1.29.0), and server-everything is already at its latest (2026.7.4) — so there is no upstream bump to wait for. An npm override is the only way off it today. Overriding a transitive major the SDK was not written against is the real risk here, so it is tested rather than assumed: with the override in place, `npm ci` resolves @hono/node-server 2.0.11 and the reference server still completes a full MCP handshake over stdio, returning all 13 tools. The image only ever runs the downstream over stdio, so it never constructs a Hono HTTP server at all — the vulnerable serve-static path was unreachable here either way. This is about not shipping a flagged dependency in a supply-chain tool's own image, not about a live exploit. Drop the override once the SDK widens its range; Dependabot watches /docker (added in #91) and will offer that bump. Verified: clean-cache `npm ci --omit=dev` with SSH disabled resolves 108 packages and pins @hono/node-server to the patched 2.0.11; live stdio handshake against that exact tree returns 13 tools. The full image build + non-root check + live handshake is what docker.yml asserts on this PR.
askalf
added a commit
that referenced
this pull request
Jul 22, 2026
…frvp-7c67-39w9) (#96) Scorecard opened a high-severity Vulnerabilities alert (#28) minutes after #91 landed. The dependency is not new — `npm i -g` was installing the same tree before — but nothing in the repo described it, so nothing could see it. The lockfile that #91 added is what made it visible, which is the point of having one. The advisory (published 2026-07-21, hours before that merge) is a path traversal in @hono/node-server's serve-static, patched in 2.0.5. It reaches this image transitively: server-everything -> @modelcontextprotocol/sdk -> @hono/node-server "^1.19.9". That caret range can never resolve to 2.0.5, the SDK is already at its latest (1.29.0), and server-everything is already at its latest (2026.7.4) — so there is no upstream bump to wait for. An npm override is the only way off it today. Overriding a transitive major the SDK was not written against is the real risk here, so it is tested rather than assumed: with the override in place, `npm ci` resolves @hono/node-server 2.0.11 and the reference server still completes a full MCP handshake over stdio, returning all 13 tools. The image only ever runs the downstream over stdio, so it never constructs a Hono HTTP server at all — the vulnerable serve-static path was unreachable here either way. This is about not shipping a flagged dependency in a supply-chain tool's own image, not about a live exploit. Drop the override once the SDK widens its range; Dependabot watches /docker (added in #91) and will offer that bump. Verified: clean-cache `npm ci --omit=dev` with SSH disabled resolves 108 packages and pins @hono/node-server to the patched 2.0.11; live stdio handshake against that exact tree returns 13 tools. The full image build + non-root check + live handshake is what docker.yml asserts on this PR.
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.
Why
Same registry create-block as warden/keeper:
canonis squatted unscoped (canon@0.4.1), and npm's create-time policy silently 403s@scope/Xwhen unscopedXexists. Operator decision: rename the trilogy. Companions: askalf/redstamp#44 (redstamp), askalf/strongroom#30 (strongroom).What
package.jsonname →@askalf/truecopy("certified true copy" — what vetting asserts), version 0.6.2, repo URLs →askalf/truecopytruecopy/truecopy-mcpbins; legacycanon/canon-mcpaliases retainedDeliberately unchanged
@askalf/wardendep pin + import specifiers — flip to@askalf/redstampin a follow-up once warden#44 mergeswatchbranch rides the repo through the rename)After merge
askalf/canon→askalf/truecopy@askalf/truecopy@0.0.1name-claimTests: 85 pass / 0 fail.