Self-Update and Releases

The self-update subcommand fetches the latest release from GitHub, verifies the binary against a pinned ed25519 key, and atomically replaces the running binary. It is implemented in wcore-cli/src/self_update.rs (v0.8.1 U9).

Basic usage

wayland-core self-update             # check and install if newer
wayland-core self-update --check-only  # print version diff, do not write to disk

--check-only prints the current and latest version strings and exits without touching the filesystem:

current: v0.9.6
latest:  v0.9.7
(check-only: not installing)

If you are already on the latest version the command prints already up to date. and exits cleanly.

What the update process does

1. Fetch release metadata. The command issues a GET to https://api.github.com/repos/TradeCanyon/wayland-core/releases/latest. The release repo is a compile-time constant (RELEASES_REPO) so a misconfigured workspace cannot redirect updates to a different repository. The HTTP client is wcore_egress::EgressClient (not raw reqwest) so the request passes through the egress policy.

2. Resolve the artifact name. The binary name is derived from the host OS and architecture:

   Host	Artifact
   macOS aarch64	wayland-core-aarch64-apple-darwin
   macOS x86_64	wayland-core-x86_64-apple-darwin
   Linux x86_64	wayland-core-x86_64-unknown-linux-gnu
   Linux aarch64	wayland-core-aarch64-unknown-linux-gnu
   Windows x86_64	wayland-core-x86_64-pc-windows-msvc.exe

3. Download. The binary and its .sig file are streamed into a temporary directory. When Content-Length is present, the downloaded byte count is verified against it. A size mismatch is a hard error; a short-write attack cannot succeed because verification still runs over whatever bytes were written.

4. Verify the signature. The .sig file contains a raw 64-byte ed25519 signature over the binary bytes. The engine verifies it against the pinned marketplace public key before writing anything to the final path. A tampered binary or a tampered signature is rejected with a SignatureVerificationFailed error and nothing is installed.

5. Atomic swap. On Unix, the new binary is chmod 755 then swapped in with self_replace::self_replace, which performs a POSIX rename. On Windows it uses MoveFileExW and handles the running-exe-lock. The swap is atomic: either the new binary is in place or the old one remains.

Signature key

The public key is pinned in the binary as MARKETPLACE_PUBKEY_B64. Release engineers can rotate the key without a code change by setting WAYLAND_SELF_UPDATE_PUBKEY_B64 in the environment; the CLI prefers the env override over the compiled-in constant. This env var is also used in tests to inject a freshly-generated keypair.

The placeholder key compiled into non-release builds is a deterministic all-zero ed25519 point. It decodes successfully but cannot validly verify any signature a release would publish, so an accidental build that ships the placeholder fails closed rather than accepting arbitrary binaries.

404 handling

If the repository exists but has no releases yet, the GitHub API returns HTTP 404. The command handles this as Ok(None) and prints a clean message rather than treating it as a broken-repo error:

current: v0.9.6
latest:  no releases published yet on TradeCanyon/wayland-core

Any other non-2xx response is a hard error.

Release channels

There is currently one release channel: latest on the TradeCanyon/wayland-core GitHub repository. Release tags have the form vX.Y.Z or vX.Y.Z-wayland-base; the version parser strips both the v prefix and the -wayland-base suffix so the displayed version matches CARGO_PKG_VERSION.

Pre-release and beta channels are not yet wired to the self-update command. To test a specific release, install it manually:

cargo install --git https://github.com/ferroxlabs/wayland-core \
    --tag v0.9.7-rc.1 wcore-cli

npm installs

If you installed through npm (npm install -g @ferroxlabs/wayland-core), update the same way:

npm install -g @ferroxlabs/wayland-core@latest

The npm package wraps the platform binary; wayland-core self-update also works for npm-installed binaries as long as the binary path is writable by the current user.