3.2 Adding a Repository
Adding a repository is the trust ceremony of PSPU §5.37: the moment an operator decides that a particular key speaks for a particular URL.
3.2.1 The ceremony #
peipkg fetches the descriptor and its detached signature, fetches the public key for each anchor fingerprint the operator supplied, checks each fetched key against the fingerprint that named it, and verifies the descriptor's signature against those anchor keys and only those. On success it records the descriptor's full key list, with statuses, as the repository's trust state.
If none of the fetched keys matches a configured anchor, the add is refused. The error lists both the configured anchor fingerprints and the fetched key fingerprints in four-character groups. Fetched fingerprints are labelled not yet trusted: this diagnostic helps compare a transcription against an independently obtained anchor; it is not a reason to adopt a key supplied by the repository itself. No trust state or index cache is recorded on this mismatch.
A matching anchor must still verify the descriptor's signature. On the success path, peipkg does not yet display a fingerprint comparison or prompt for confirmation before recording trust.
3.2.2 Two forms #
peipkg repo add <name> <url> --anchor <fingerprint> is the interactive
form: everything comes from the command line.
peipkg repo add <name> is the configured form: the URL, the anchors,
and the policy are already on disk, placed there by an image or a
configuration manager, and the command performs the ceremony against
them. When the ceremony fails for a repository whose configuration file
already existed, that file is deliberately left in place — the operator
put it there, and deleting it would discard their configuration over a
transient network failure.
3.2.3 Bootstrapping the freshness floor #
The first index a repository serves establishes the floor that §3.4's rollback protection enforces from then on. A repository that publishes a minimum acceptable index version alongside its anchors lets peipkg refuse an add whose first index falls below it; without one the floor is whatever the first fetch returned.
Adding a repository that is already configured does not reset the recorded floor. The configured form of the command needs no arguments and reads as idempotent, so a convergence loop or a re-provisioning script runs it routinely; it re-runs the anchor ceremony and adopts the served descriptor's trust state, but the served index passes the same freshness gate a refresh applies (§3.4). An index below the recorded floor is refused, and one exactly at it counts as no progress, so the last-refresh time does not advance either.
Removing a repository is the only route that clears a floor, and it clears the whole recorded trust state with it. That is what makes lowering a floor an explicit operator act rather than the side effect of a command that looks like a no-op.
3.2.4 Fetching keys before verifying #
The descriptor names the URLs its keys are published at, so peipkg reads an unverified document to know where to fetch from. It fetches every key the descriptor declares, not only those matching the supplied anchors.
3.2.5 Official anchors #
The anchors for the official repository come from a file installed by the base system, outside any package. Bootstrap trust is a property of the image rather than of the package format: peipkg relies on the anchors being present when it first runs.