Revoke a version

Revoking is the hard stop. It marks one version as revoked: nobody can install it, and installs already on it are disabled, normally within about a minute. It cannot be undone.

Revoke, must-upgrade, or neither?

There is no vendor-facing delete: deleting a version under live installs would leave them pointing at nothing.

When to revoke

• A security problem: a secret in the bundle, an over-broad entitlement, a tool that does more than it declares.

• A bug where running is worse than stopping: data corruption, calls to the wrong upstream.

• A mistaken publish: wrong version number, wrong tier, a draft that escaped.

Who can revoke

You, for any version under your own scope, and OPVS, for anything, in an emergency. The manifest's revocable_by can name others.

How to revoke

# the version's id
curl -s "https://market.opvs.ai/api/v1/registry/packages/@acme/leads/1.2.0" \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['id'])"

curl -X POST "https://market.opvs.ai/api/v1/registry/packages/<package_id>/revoke" \
  -H "X-Admin-Key: $OPVS_PARTNER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "secret included in the bundle; fixed in 1.2.1"}'

A 403 means the package is not in your scope.

What happens

revoke call
  ├─▶ the version becomes 'revoked'            immediately: no new installs
  └─▶ OPVS's poller disables every install on it   within about a minute
         └─▶ calls to its tools stop on the next call

A workspace on a revoked version sees the package as disabled and its tools stop answering. It recovers by installing a good version.

Do it in this order

1. Publish the fix first, so workspaces have somewhere to go.

2. Announce it: a CHANGELOG.md entry on the fix (what was wrong, which version is safe) and a direct notice.

3. Then revoke the bad version.

Never revoke first and look for a fix while workspaces are down.

Revoking a version is not the same as rotating a key. For leaked credentials see Rotate a credential.