GET /api/v1/marketplace/install-local serves the installed-package ledger to anonymous callers — no authentication at all

[qq9340100]

Found while implementing #8976 (the capability gate on the four mutating install-local routes). Out of scope there by ruling — that card's 裁决 names the four mutating doors and says the fix is authorization on those — so filing separately rather than riding it in. Unassigned.

Measured (origin/main, packages/cloud-connection/src/marketplace-install-local-plugin.ts)

handleList — the handler mounted at GET /api/v1/marketplace/install-local — calls no identity resolution whatsoever. Its first statement reads the ledger:

private handleList = async (c: any, ctx: PluginContext): Promise<Response> => {
 const { entries, skipped } = this.readAll();

The four sibling routes (POST /install-local, DELETE …/install-local/:id, …/reseed-sample-data, …/purge-sample-data) each opened with requireAuthenticatedUser before #8976 and now open with a manage_metadata capability gate. The GET opens with nothing — it is not a weaker gate, it is the absence of one, so an anonymous caller who can reach the port gets a 200.

Re-check by symbol (line numbers in this repo go stale within hours):

git grep -n "handleList" -- packages/cloud-connection/src/marketplace-install-local-plugin.ts
git grep -n "rawApp.get(ROUTE_BASE" -- packages/cloud-connection/src/marketplace-install-local-plugin.ts

What the response body discloses

Per ledger entry: packageId, versionId, manifestId, version, installedAt, installedBy, withSampleData — plus, once per response, storageDir.

• installedBy is a platform user id, and the listing enumerates them across every install.
• storageDir is an absolute filesystem path on the host (#6721 added it deliberately, for a signed-in CLI operator who cannot see the remote host's disk).
• The package inventory itself is a version-level software bill of materials for the deployment — which packages, at which versions, installed when.

Why it is worth a decision rather than an obvious patch

The mount is deliberately unconditional (cloud#1287, so air-gapped boxes stop 404ing), and the console's "Installed Apps" page is a real consumer of this route, so the question is which posture the read should take, not whether to remove it. At least three defensible answers:

1. Authenticated floor — any signed-in principal may list. Cheapest, matches "the console shows it in Setup".
2. The same manage_metadata the write doors now demand — consistent with the operator-grade framing of the surface, but would hide the Installed Apps list from non-operator users the console currently shows it to.
3. Authenticated floor + field narrowing — list the packages, drop installedBy and storageDir for callers without an authoring capability. Splits "what is installed here" from "who installed it and where it lives on disk", which are genuinely different sensitivities.

The storageDir half interacts with #6721's stated purpose, so whichever way it goes should be decided knowingly rather than as a side effect.

Severity

Read-only disclosure, so lower than #8976's write channel — but it needs no credential of any kind, and on the walled multi-org EE shape (cloud#1331's surveyed deployment) the inventory and the installer identities are cross-tenant information the Layer 0 wall does not scope either, for the same reason: metadata is environment-scoped, not org-scoped.

Related: #8976 (the mutating routes; now gated), #6603 / #8919 (the /meta write-door precedent), cloud#1331 (walled-deployment context), #6721 (why storageDir is in this payload).

[os-project-manager]

Triage: needs-user-decision + domain:cli (packages/cloud-connection per the lane table) + security + target:v17 + type Bug. Security/permission-boundary posture choice = human floor — not auto-adjudicable even though every option tightens. Board rationale: same class as #8976 (published operator surface, declared≠enforced auth posture, cross-tenant on the walled EE shape); read-only, but it needs no credential at all and disclosure includes platform user ids and a host filesystem path.

Four-axis card face

1. Platform long-term coherence: after install-local routes accept any authenticated session (plus an x-user-id header fallback) — a schema-mutating channel with no capability check, cross-tenant on walled multi-org deployments #8976 the four write doors are capability-gated; this GET is the only anonymous door left on the surface. Option 3 gives one coherent posture — reads authenticated, operator-grade fields (installedBy, storageDir) operator-only — instead of a third ad-hoc level.
2. Measured business pull: the console "Installed Apps" page is a real, signed-in consumer. No anonymous consumer is known — cloud#1287's unconditional mount was about the route existing on air-gapped boxes (stop 404ing), not about serving anonymous callers. Option 2 would hide the page from non-operator users the console ships it to today — a regression with real pull against it.
3. AI-agent error-resistance: an explicit auth floor plus an explicit field allowlist is declarative and testable; "whole ledger to whoever asks" is exactly the silent-tolerance shape the platform is eradicating. A pinned test per posture (anonymous → 401; non-operator → no storageDir/installedBy; operator → full) closes it.
4. Startup scope discipline: option 1 is one line; option 3 adds a small response filter. Option 2 is cheap in code but costs a shipped console behavior. No new capability minted under any option (The REST /meta publish and rollback doors carry no manage_metadata gate, so the authoring capability the PUT/DELETE doors enforce is reachable around #8919 discipline).

Recommendation: Option 3 — authenticated floor for the list, drop installedBy + storageDir unless the caller holds manage_metadata; option 1 acceptable as the minimum if field narrowing is judged over-engineering. Fork clause for the implementer: if any console/CLI path is found fetching this route unauthenticated, stop and report — that is a fork, not something to route around.

Serial constraint: same file as #8976 (in flight, marketplace-install-local-plugin.ts). Whenever ruled, re-verify the handler shape on the post-#8976 merged ref before dispatch; never same-batch with #8976.

Dedupe checked: distinct from #8976 (absence of any gate vs. wrong gate on the write doors); no other open card on this route.

Triage: this comment comes from the triage seat Routine; not a claim.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-16, recorded by PM session session_01NYgmGheCzM6NrHZN436Cxf). The maintainer reviewed the evening decision-inbox report and accepted its recommendations in full, verbatim: 「8931 我已经处理了，其他接受你的所有建议。」 For this card the accepted recommendation was:

Ruled: Option 3 — authenticated floor + field narrowing.

• GET /api/v1/marketplace/install-local requires an authenticated principal (anonymous → 401).
• installedBy and storageDir are returned only to callers holding manage_metadata; other authenticated callers get the package inventory without them.
• Pinned tests per posture: anonymous → 401; non-operator → no installedBy/storageDir; operator → full payload.
• Fork clause (binding, from triage): if any console/CLI path is found fetching this route unauthenticated, stop and report — do not route around it.
• Serial constraint: same file as install-local routes accept any authenticated session (plus an x-user-id header fallback) — a schema-mutating channel with no capability check, cross-tenant on walled multi-org deployments #8976's fix — re-verify the handler shape on the post-install-local routes accept any authenticated session (plus an x-user-id header fallback) — a schema-mutating channel with no capability check, cross-tenant on walled multi-org deployments #8976 merged ref before dispatch; never same-batch with any open work on marketplace-install-local-plugin.ts.

target:v17 stays — this is a release blocker until landed. Label flipped needs-user-decision → pm:queue in the same stroke.

---

Generated by Claude Code