greentic-update
Foundation library for the Greentic update platform — a secure, pull-based update mechanism for both internet-connected and airgapped Greentic environments.
This crate is the transport-agnostic core, consumed by:
greentic-deployer(the operator CLI) for theop get-updates/op apply-updatesverbs;- the Public Updater Bridge binary, for airgapped transfer onto removable media;
- the cloud Update Planner (greentic-biz), which builds and signs update plans.
Design principles
- Deterministic and signed by default. An update plan is a DSSE-signed
in-toto
Statement; every artifact is content-addressed and digest-verified. Verification is fail-closed against a per-environment trust root. - No parallel apply engine. A plan's
targetis agreentic.env-manifest.v1document (carried here as opaque JSON); applying an update drives the existingenv_applypipeline and revision lifecycle ingreentic-deployer. - Lean dependencies. This crate does not depend on
greentic-deploy-spec. Callers project their domain types into the lightweight artifact view defined here. The only workspace dependency isgreentic-distributor-client, reused for DSSE/in-toto signing and the content-addressed download client.
Modules
| Module | Purpose | Phase |
|---|---|---|
plan |
Signed greentic.update-plan.v1 build/verify |
P0a |
catalogue |
Installed-artifact view + diff against a plan's artifacts | P0c |
staging |
On-disk {downloading,inbox,staged,applying,…} state machine |
P2 |
envelope |
Airgap update-bundle wrapper + import scanner | P5 |
binswap |
Verified on-disk binary swap + rollback (binary self-update) | P7 |
Status: in production use on the dev lane.
plan,catalogue,staging,envelopeandbinswapare all shipped and consumed bygreentic-deployer(op updates …) andgreentic-start(staging, apply, binary self-update). The airgap delivery path is complete through Tier 2 in-gap serving — see docs/airgap-update-delivery.md.
Build & test
# or the full local gate:
License
MIT