security: load the exact distribution approved by extension discovery

[codeforester]

Problem

ExtensionDiscovery filters descriptors by distribution allowlist, but loading re-searches raw entry points using only group, name, and value. A denied distribution with an identical entry-point triple can be loaded instead of the approved distribution. This violates the advertised selection boundary; it does not imply installed Python plugins are sandboxed.

Verified evidence

Reviewed on 2026-09-12 at 7faf347a5b90969e169c88f3ac18e7202d142dd0; the local checkout matches GitHub main.

Use two synthetic entry points in this order, both with group base_cli.plugins, name demo, and value same.module:plugin. Their distributions are denied and trusted; each load method only appends its distribution name to a list and returns it.

discovery = ExtensionDiscovery(entry_points=[denied, trusted], allowlist=["trusted"])
discovery.list() -> one descriptor, distribution="trusted"
discovery.load("base_cli.plugins", "demo") -> "denied"
load calls -> ["denied"]

The reproducer executes no external plugin code. _load_descriptor() selects the first raw triple, losing the distribution identity used by _allowed().

Sources:

• lib/python/base_cli/extensions.py
• docs/extensions.md

Acceptance criteria

• Bind the approved descriptor to its exact source entry point/distribution and version.
• Never invoke a filtered-out entry point when identifiers collide.
• Define fail-closed behavior for ambiguous or changed identities and refresh.
• Cover denied-first/trusted-first order, same-name/value collisions, load_all, cached loads and refresh using harmless fixture loaders.

Related work

Related to #243, but this is a distinct defect in the already-shipped allowlist implementation.

Project fields

• Status: Backlog
• Priority: P1
• Area: Security
• Initiative: v1.0 Readiness
• Size: M
• Assignee: @codeforester
• Milestone: v1.0.0
• Target date: unscheduled