appcore-update
Stable 1.0.0 · MSRV Rust 1.89 · crates.io · docs.rs · code source
Guide et exemples maintenus par le crate
Le dépôt Runtime maintient le guide détaillé, exemple débutant et exemple intermédiaire. Le wiki résume la frontière publique ; les détails d’API et d’exécution restent avec le code du crate.
Responsabilité : sélection, authenticité, staging, activation, health gate et rollback d'artefact opaque.
Dépendances internes : contracts et provider.
API principale : artifact descriptor/signing payload; verifier, unsigned-local protégé par feature/Ed25519, trust policy/key status; update request/provider et file factory; staged artifact, activation receipt/store; coordinator, preparation/outcome, health check et fault injection.
À utiliser pour binaires ou artefacts opaques. Le Runtime valide identité, version, protocole, checksum et trust sans comprendre code ou schéma.
Les lectures fichier vérifient la taille avant l'allocation, utilisent un scratch fixe de 16 Kio plus un octet sentinelle non retenu et rejettent un composant final non régulier. L'activation revalide taille et SHA-256 du staged, puis crée un hard link vers un path de build immuable. Un path existant n'est réutilisé que si ses octets correspondent exactement au descriptor; il n'est jamais remplacé. Le no-follow atomique du composant final existe sous Unix. Les autres plateformes conservent les checks metadata mais dépendent de la frontière filesystem du déploiement contre les races de reparse.
Les pointers active/previous et les receipts d'activation pending empruntent leurs descriptors, passent un sizing sans rétention sous 1 Mio et sérialisent directement dans le temporaire atomique avec un buffer fixe de 16 Kio. Leur lecture désérialise aussi directement par un reader borné fixe de 16 Kio, sans conserver un vecteur complet d'octets encodés avec le pointer ou receipt décodé. L'absence, l'échec d'I/O et l'échec de décodage restent distincts afin de préserver l'upgrade wall de l'activation pending. Le JSON V1 reste inchangé.
Le file provider parcourt une seule fois l'index borné en streaming et ne retient que la meilleure version sémantique et son descriptor. Chaque descriptor est validé puis éliminé ou sélectionné pendant le décodage du tableau JSON, sans vecteur de descriptors ni liste triée de candidats. À version égale, la première entrée reste prioritaire. Un reader fixe de 16 Kio, un preflight de 1 Mio et un octet sentinelle non retenu rejettent une taille déclarée excessive et une croissance concurrente.
Maturité : lifecycle stable; supply chain distant exige signature, provenance et trust roots.