​
Provider autoupdate

How a provider Mac moves to a newer signed release without manual steps.
Providers installed through the Malibu app or the standard installer upgrade themselves to newer signed releases. The network tells each provider which version it recommends. The provider verifies that release, drains its in-flight requests, and swaps the whole signed release set in place: CLI, companion files, and the Malibu app if it is installed.

​
The flow

  1. Advertisement. When a provider connects, the network’s handshake reply includes a recommended_binary_version, plus a minimum required version.
  2. Eligibility. The provider updates only if all of these hold:
    • the advertised version is newer than the running one;
    • autoupdate is enabled;
    • the target is not revoked or below the signed minimum;
    • the install is a standard user install (live.malibu.provider launchd agent).
    Provisional (not yet pinned) providers are eligible by default.
  3. Fetch. The provider downloads that release from GitHub Releases (Augustas11/macprovider). It needs the CLI tarball, the Malibu-vX.Y.Z.dmg, the compatibility index, checksums.txt, and checksums.txt.sig. If any asset is missing, the update fails.
  4. Verify.
    • checksums.txt.sig must verify against the release-signing public key built into the running binary. Every asset must match checksums.txt.
    • The release’s compatibility set must match the one the network expects.
    • The staged CLI and Malibu app must pass a strict code-signature check against Malibu’s Developer ID team.
  5. Drain. The provider tells the network it is draining, which stops new requests from being routed to it, and waits for in-flight requests to finish. If requests are still running after the bounded wait (about two and a half minutes), the update is abandoned (drain_timeout) rather than cutting a buyer off. It is retried later.
  6. Swap. Files are replaced in the install directory (~/macprovider/), and a backup of the previous binary is kept alongside. If the Malibu app is installed, it is replaced from the signed DMG in the same transaction.
  7. Restart and health check. launchd restarts live.malibu.provider. The new version has to pass a run of consecutive local health checks. If it doesn’t, the swap is rolled back to the previous binary automatically.
If a provider is connected but keeps failing to make progress, it can recover through a signed release-discovery file published with each release, without waiting on the network’s recommendation.

​
Check or update manually

In the Malibu app, Check for Updates… in the menu bar runs the same update and relaunches the app.

​
Opting out

Autoupdate is on by default. To turn it off, set this in ~/.config/macprovider/config.yaml:
The environment equivalent is MACPROVIDER_AUTO_UPDATE_ENABLED=false. When it is off, the provider logs that a newer version is available and does nothing else. You then have to run malibu-cli update yourself. Don’t opt out casually. The network sets a minimum supported version. A provider that falls below it can be refused admission until it updates. Headless (SSH-only) installs are never autoupdated. The installer writes auto_update_enabled: false for them, and they are upgraded by the operator. See Headless install.

​
Recovering a stuck update

If an update was interrupted, for example by power loss mid-swap, and the provider refuses to serve, run:
recover-update clears only an abandoned update or rollback transaction. It leaves a genuinely in-progress update alone and is safe to run while the provider is stopped. If that doesn’t help, re-running the installer repairs the install in place.

​
Signed release verification

Each release carries a checksums.txt manifest signed with Malibu’s release key (ECDSA P-256). The matching public key is compiled into the provider binary, so a compromised download mirror cannot produce an update that verifies. On top of that, the release set must match a signed compatibility set, and the binaries must pass the Developer ID code-signature check.