Enterprise mirror

Planned — not yet available. There is no published reference mirror container or qualified disconnected installation workflow. This page describes current constraints and the work required before offering one.

What is supported now

The CLI accepts --catalog-base <url> as an explicit catalog transport option. It still verifies against its pinned catalog key. A different metadata base does not rewrite the artifact URLs contained in signed entries: the current catalog schema pins release URLs to https://rave.maccrab.com/.

Consequently, copying metadata to an internal server does not provide an air-gapped install. URL query overrides such as ?catalog= are also rejected by the app’s install-link parser. There is no supported Rave maccrabctl channel add workflow or production enterprise-key registration procedure documented here.

Requirements for a mirror release

A complete design must preserve the index, individual entries, revocation documents, archives, and detached signatures; resolve artifacts on the intended transport; and qualify install/update/revocation behavior while disconnected. It also needs a tested synchronization/recovery process and an explicit offline freshness policy.

Pass-through transport can preserve signed bytes. Editing an index to remove entries or changing release_url_template invalidates its signature. Skipping archive files leaves entries discoverable but unavailable; it does not create a smaller signed catalog. A curated catalog or replacement signing key requires a separately supported trust-policy and publication design.

Plugin signatures establish content integrity relative to a trusted publisher key. The catalog key is the trust anchor for the publisher endorsement. Fetching both a key and its fingerprint from the same untrusted mirror does not independently establish trust; use a trusted app distribution or a separately authenticated key record.

Freshness and revocation

A valid signature does not establish that a document is the latest publication. Existing clients track accepted serials to reject rollback relative to their recorded history. This cannot prove the first document seen is current.

The app’s existing freshness display tracks time since a successful revocation fetch. That is different from signed issue time: fetching an old signed document today does not make it newly issued. The earlier proposed 30/90-day mirror banners are not a released contract.

Before promising offline operation, define maximum offline duration, signed-document renewal if expiry is introduced, key rotation, clock behavior, and how operators receive revocations. A successful offline signature check alone does not show that a plugin remains trusted now.

For deployment requirements or interest in a future mirror release, contact [email protected]. See current status, verification, and the URL contract.