Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Zebra crates

The workspace publishes 12 crates:

  • zebrad
  • zebra-chain, zebra-consensus, zebra-network, zebra-node-services
  • zebra-rpc, zebra-script, zebra-state, zebra-test, zebra-utils
  • tower-batch-control, tower-fallback

Each of these crates has the following crates.io owners, verified on October 24, 2026:

OwnerKind
conradoplgIndividual
oxarbitrageIndividual
github:zcashfoundation:ownersGitHub team

The owners team listing includes other Foundation projects. Inspect the registry’s live list before changing ownership:

cargo owner --list zebrad

Logging in to crates.io

Normal releases use Trusted Publishing: the release workflow obtains short-lived crates.io credentials through GitHub Actions OpenID Connect and publishes from the approved source.

A crate owner must configure each crate’s Trusted Publisher with repository ZcashFoundation/zebra, workflow release.yml, and environment release. Repository CI cannot inspect these owner-only bindings. Confirm them before the first automated publication of a crate.

Manual ownership changes, authorized yanks, and exceptional publication require a crates.io token. Create it in account settings, restrict it to the required crates and operation, and set the shortest practical expiry.

Authenticate interactively rather than putting the token in shell history:

cargo login

Revoke the token in account settings after the operation. Do not put registry tokens in committed configuration, command output, or issue reports.

Publishing new crates

Agree on the crate’s purpose and name before publication, which a Git revert cannot undo:

  1. Add its manifest and workspace membership through review. Confirm its package name, license, repository metadata, dependencies, and publication settings.
  2. Add its project mapping and initial changelog source to .changie.yaml and .changes/ before generation. A project with no version history is rendered as only the shared header; do not add an existing crate without migrating its changelog history.
  3. Review the version and changelog in the release process. Arrange an authorized API-token first publication: crates.io requires the crate to exist before Trusted Publishing can be configured. Use the normal controller for subsequent releases.
  4. Add the required owners, confirm acceptance and the live list, and configure Trusted Publishing before automated publication.

Never run a second publisher alongside the release controller.

Changing crate ownership

Both individual and team owners can publish and yank versions. Only individual owners can change the owner set; see Cargo’s ownership reference. Keep at least two individual owners and the Foundation team on each crate.

Invite replacements before removing a departing maintainer. Individual invitees must accept on crates.io before they appear as owners. Set CRATE, NEW_OWNER, and OLD_OWNER to the approved crate and GitHub logins:

cargo owner --list "${CRATE}"
cargo owner --add "${NEW_OWNER}" "${CRATE}"
cargo owner --add github:zcashfoundation:owners "${CRATE}"

After the replacement accepts, inspect the list and remove only the intended former owner:

cargo owner --list "${CRATE}"
cargo owner --remove "${OLD_OWNER}" "${CRATE}"
cargo owner --list "${CRATE}"

These commands require no checkout, even for crates outside the workspace.