Summary
npm audit signatures cannot verify a dependency tree that contains toolcraft, because the packages Toolcraft bundles into its tarball are not published to the registry and therefore have no identity at npm's signature-audit endpoint. The audit stops at the first such package — in practice the bundled tiny-mcp-client@0.1.0.
Reproduction
mkdir consumer && cd consumer && npm init -y
npm install toolcraft@0.0.87
npm audit signatures
The audit fails to resolve the bundled packages. All eleven packages inside the tarball's node_modules are affected — npm view returns E404 for each (e.g. tiny-mcp-client, toolcraft-design, @poe-code/frontmatter); the full list is in #495.
By contrast, a production tree with Toolcraft excluded verifies cleanly, which is the current downstream workaround: signature audits run only in trees where the Toolcraft closure is absent (the packed-SDK consumer install and the production app tree), and the CLI bundle's own inputs are covered by separate byte-for-byte artifact checks instead of registry signatures. That means the one tree where supply-chain verification matters most — the inputs to the shipped CLI binary — is exactly the tree npm audit signatures cannot attest.
Requested fix
Make every package identity that ships inside the toolcraft tarball resolvable by npm audit signatures. The straightforward path is to publish each first-party bundled package to npm (even if consumers are never expected to install them directly), so registry signatures and provenance attestations exist for the exact name@version pairs that appear in the tarball. Alternatives that achieve the same attestability are equally welcome.
Acceptance criteria
- In a clean project,
npm install toolcraft && npm audit signatures completes with all packages verified, including everything under node_modules/toolcraft/node_modules/.
- A release check prevents shipping a tarball containing a bundled
name@version that the signature-audit endpoint cannot resolve.
Summary
npm audit signaturescannot verify a dependency tree that containstoolcraft, because the packages Toolcraft bundles into its tarball are not published to the registry and therefore have no identity at npm's signature-audit endpoint. The audit stops at the first such package — in practice the bundledtiny-mcp-client@0.1.0.Reproduction
The audit fails to resolve the bundled packages. All eleven packages inside the tarball's
node_modulesare affected —npm viewreturns E404 for each (e.g.tiny-mcp-client,toolcraft-design,@poe-code/frontmatter); the full list is in #495.By contrast, a production tree with Toolcraft excluded verifies cleanly, which is the current downstream workaround: signature audits run only in trees where the Toolcraft closure is absent (the packed-SDK consumer install and the production app tree), and the CLI bundle's own inputs are covered by separate byte-for-byte artifact checks instead of registry signatures. That means the one tree where supply-chain verification matters most — the inputs to the shipped CLI binary — is exactly the tree
npm audit signaturescannot attest.Requested fix
Make every package identity that ships inside the
toolcrafttarball resolvable bynpm audit signatures. The straightforward path is to publish each first-party bundled package to npm (even if consumers are never expected to install them directly), so registry signatures and provenance attestations exist for the exactname@versionpairs that appear in the tarball. Alternatives that achieve the same attestability are equally welcome.Acceptance criteria
npm install toolcraft && npm audit signaturescompletes with all packages verified, including everything undernode_modules/toolcraft/node_modules/.name@versionthat the signature-audit endpoint cannot resolve.