Skip to content

[P1] Package registry: add authorized signed trust and real resolver distribution #304

Description

@wsdt

[P1] Package registry: add authorized signed trust and real resolver distribution

Review baseline and scope

Reviewed source: c9d32008e98d0e1711f47cb739f61c42376b884e on main, 22 September 2026.
Classification: TRUST / DISTRIBUTION INTEGRATION.
Predecessors: #195.
This replaces their remaining work; closing a predecessor during backlog migration is not a claim that its original scope was completed.

Already delivered — do not rebuild

f6ef8e5 supplies canonical raw lock/fetch and a clean project-consumer bridge with swapped-subject rejection. 948230a adds Package Artifact Manifest v1 and registry snapshot/document v2, admitted only through verified Linked Build-v2 and exact subject/API/artifact bindings. These are local read-only contracts, not signing, publication, cache, network or a hosted registry.

Remaining implementation / execution

  • Implement the remaining authenticated publisher/signature/trust-policy boundary and explicit revocation/yank handling, reusing the verified manifest and signed-release primitives.
  • Provide the intended bounded distribution/cache/mirror and reproducible resolver workflow under explicit host/network authority; keep lock and fetched artifact bytes inseparable.
  • Exercise clean offline/online-as-authorized consumption, swapped/tampered/stale metadata, wrong identity, rollback, revocation, unavailable mirrors and reproducible resolution.

Acceptance evidence

  • A real authorized publisher/registry path verifies exact source/build/artifact/API provenance and refuses decoded-but-unadmitted evidence.
  • The same trusted inputs resolve to identical locks and package bytes; no mutable alias, hidden network or arbitrary install script can bypass the contract.
  • Trust decisions, supported distribution scope and hosted acceptance are explicitly recorded.

Integration dependencies

These identify related acceptance work; safe independent implementation can proceed in parallel where the owning contracts permit it.

Boundaries

Do not rebuild the raw consumer bridge or manifest-v2 decoder; do not publish or sign from the issue-refresh script. A task description is not an authorization for provider spend, signing, publication, remote deployment or a change to support policy. Preserve existing stable identities, explicit profile limits, source authority and non-vacuous acceptance gates.

Evidence and implementation entry points

Test results described above are retained repository evidence, not a fresh full test run performed by this backlog review. Re-run the owning gates for the implementation being accepted.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions