[Bug] Plugin Manager rejects or misclassifies HTTP tarball URLs with query parameters

[GCSimba]

Current-version update — 2026-10-07

Rechecked on 2026-10-07 against the newest public release, 0.2.1-alpha.1, and upstream master at 5badb15009ae1756c3afe0ae0cef1faafc290ccc. The query-bearing tarball fix remains applicable. The owning install-spec/manager selection passed 105 cases, registry passed 15, and the assembled Chromium install scenario passed. All five product commits are preserved in the published current-baseline integration; both the full build and full lint passed.

Current patch index and verification limits. No all-checks-pass, upstream acceptance or released-fix claim is made. This update is AI-assisted with Codex; the published commits retain its co-author.

The original report and its verification history are preserved below.

---

Summary

On master at 5badb15009ae1756c3afe0ae0cef1faafc290ccc (0.2.1-alpha.1), Plugin Manager does not recognize an HTTP(S) archive pathname when the URL has a query after the archive extension. Depending on path depth, it either rejects the spec before pnpm runs or reports the archive as a Git repository.

This affects archive URLs with download, token, or signature parameters. I identified this during a source audit and did not find an equivalent public report in the Discussions, Issues/PRs, relevant commits, and indexed forks I checked. That describes the public search, not a claim that nobody has encountered it privately.

Reproduction

Call parseInstallSpec with these specs on the baseline:

import { parseInstallSpec } from './packages/boot/plugin-manager/src/install-spec.ts'

for (const spec of [
  'https://cdn.example.com/plugin.tgz?token=probe',
  'https://cdn.example.com/packages/plugin.tgz?token=probe',
  'https://cdn.example.com/x/y/plugin.tar.gz?token=probe&download=1#archive',
]) {
  try {
    console.log(parseInstallSpec(spec))
  } catch (error) {
    console.log({ spec, error: error.message })
  }
}

With repository dependencies installed, save this as repro.mjs at the repository root and run node --import tsx/esm repro.mjs.

URL path plus query	Expected kind	Baseline result
/plugin.tgz?token=probe	tarball	InvalidInstallSpecError
/packages/plugin.tgz?token=probe	tarball	git
/x/y/plugin.tar.gz?token=probe&download=1#archive	tarball	InvalidInstallSpecError

For rejected URLs, the Web install flow stops at inspection, before pnpm downloads anything.

As an independent control, pnpm 11.7.0 accepted a real tarball served from a loopback HTTP server at /plugin.tgz?token=probe. pnpm add --lockfile-only --ignore-scripts <URL> exited 0; the server received the complete query and the resulting manifest retained the complete URL. The archive was generated locally and no downloaded lifecycle scripts were run.

The same control passed for /download?file=plugin.tgz, which the existing parser already accepts. The patch retains that form rather than tightening the accepted URL set.

Root cause

In the baseline parser, TARBALL_SPEC checks the end of the complete spec. A query after .tgz or .tar.gz prevents its suffix match. HOSTED_REPOSITORY_URL runs before HTTP archive handling; a two-segment archive path with a query can therefore match the Git heuristic instead.

The problem is in Plugin Manager classification, not archive downloading. Discussion #8294 describes a separate pnpm integrity failure after resolving an archive; this patch does not address that issue.

Patch

• Parse HTTP(S) URLs and also recognize supported archive extensions in url.pathname, before accepting the hosted-repository heuristic.
• Retain the existing complete-spec archive check, including query-named download endpoints.
• Pass the original trimmed spec to pnpm unchanged. No query parameters are stripped and the spec is not replaced with a normalized URL serialization.
• Keep local paths and non-HTTP Git specs unchanged. Malformed HTTP(S) URLs use the existing InvalidInstallSpecError.

The only production file changed is install-spec.ts. Public TypeScript types, package exports, dependencies, configuration, profile formats, and wire formats are unchanged. The README and a bilingual Agent Note document the behavior and the decision to retain already accepted URL forms.

• Tarball classification fix — efb82abedb7641d97b64f852e10e63421ed1ae44
• Separate website test-fixture fix — c92f3aaf12d29333b0b84c0bc9fa34e42deb9d70
• Fork branch: codex/fix-tarball-url-query

The separate fixture-only commit removes a Windows file-symlink privilege dependency from the website test without changing publishing logic or skipping its containment assertion. The complete branch validation includes both commits; the tarball change remains separately cherry-pickable.

In accordance with the current contribution policy, I am sharing the report and fork patch here rather than opening an external PR.

Verification

The parser regression was run before the fix: 4 failed, 6 passed, and 8 other cases were not selected. The failures were the query-bearing archive cases; the existing query-named download endpoints remained accepted.

After the fix:

corepack pnpm exec vitest run packages/boot/plugin-manager/tests/install-spec.spec.ts packages/boot/plugin-manager/tests/manager.spec.ts packages/boot/plugin-manager/tests/registry.spec.ts --coverage --coverage.include='packages/boot/plugin-manager/src/install-spec.ts'

Result: 3 files and 120 tests passed. The modified production module has 100% statements, branches, functions, and lines coverage. The manager tests use the real Loader-backed entry and verify that archive inspection does not perform a registry package lookup; attribution tests distinguish source-host and registry download failures.

A keyless assembled Web scenario passed in Chromium with:

DSH_SNAPSHOT=replay corepack pnpm exec vitest run --config vitest.web.config.ts apps/web/tests/plugin-install-tarball.e2e.ts

The test uses the real Host/RPC/Loader/inspection/UI flow and replaces only the external package-manager process. It checks the archive label and ARIA golden, the complete spec in the child process argv, cancellation preserving the manifest, child-process termination, and an empty page-error list. In PowerShell, DSH_SNAPSHOT was set and restored explicitly around this command.

Additional checks:

• corepack pnpm run build — passed.
• corepack pnpm run doc-sync — the final complete run passed: 42 gates, 0 failed, 0 skipped. An initial Windows EPERM in the website test's file-symlink setup was independently reproduced and addressed in the separate fixture-only commit. The test now reaches the external file through a real directory junction, verifies its realpath, and retains both containment assertions. A temporary negative control that removed realpath resolution failed at the expected rejection assertion; publishing logic was then restored unchanged. All 151 website tests and two concurrent independent focused runs passed. No test was skipped or weakened and no host privileges were changed.
• corepack pnpm run lint:contracts-ready — passed for the main patch using freshly generated Host declarations; the additional fixture passed corepack pnpm exec tsx scripts/run-oxlint.ts scripts/project-doc-site.spec.ts and staged lint.
• git diff --check, staged whitespace, and committed-diff whitespace checks — passed.
• Normal pre-commit hooks — passed, including staged translation pairing and lint; no hooks were bypassed.
• Normal pre-push typecheck hook — passed; local and fetched remote branch heads match.

Limits

The local runs were on Windows with Node 24.19.0, pnpm 11.7.0, and Chromium 149. I have not claimed a completed platform CI matrix or tested a real CDN's signed-authentication integration. Recognizing an archive URL does not prove that its signature is valid, the remote bytes form an archive, or the installed package is a bundle; fetching and existing post-install validation still decide those matters.

AI-assisted source audit, implementation, and verification with Codex. Both commits include Co-authored-by: Codex <noreply@openai.com>. Only checks actually run are listed above.

[luoyukun3-oss]

Same on the released line (0.1.7-rc.2), and it comes down to one regex:

@deepseek-ai/dsh-plugin-manager/lib/index.js:33

const TARBALL_SPEC = /\.(?:tgz|tar\.gz)(?:#.*)?$/i;

The extension has to be at the very end, followed only by an optional #fragment. A ?query after
the extension therefore stops the spec from being a tarball at all, and then which of your two
outcomes you get depends on path depth — exactly as you describe:

• two segments, e.g. https://host/owner/pkg.tgz?token=x: :24
HOSTED_REPOSITORY_URL = /^https?:\/\/[^/]+\/[^/]+\/[^/#]+(?:\.git)?(?:#.*)?$/i allows ? inside
  the last segment, so it matches and the archive is reported as a Git repository;
• one segment, e.g. https://host/pkg.tgz?token=x: that pattern needs two path segments, so nothing
  matches and control reaches :100 throw invalid(spec, "a URL must point at a git repository or a tarball")
  before pnpm is ever invoked.

So this is not master-only either, and the fix is a single anchored pattern: allow a query string
after the extension, while keeping the #fragment handling intact.