Packages et signatures

Formats distribués#

Ce ne sont pas des archives ZIP. Pour les plugins et thèmes, le packaging assemble les imports JavaScript statiques avec esbuild, dont les helpers SDK et dépendances npm. Les imports non résolus, modules natifs additionnels, assets arbitraires ou dépendances nécessitant des fichiers externes ne constituent pas un format pris en charge. Les modules intégrés Node restent disponibles au code de confiance. Les packs de langue restent déclaratifs ; les packs de démarrage embarquent des modules signés qui gardent leurs propres limites de confiance.

Le manifest d’un plugin ou thème exige entry: index.mjs et un identifiant éditeur.extension. Le bundle est produit avant calcul d’empreinte et signature, jamais modifié après. Aucun lien vers le checkout n’est nécessaire dans le stockage de l’instance.

Politique commune au packaging et au registre#

La CLI et le registre analysent le module final avec esbuild. Les imports, réexports et require() littéraux ne peuvent laisser externes que des modules Node reconnus par isBuiltin(). SDK, React, packages npm et fichiers locaux doivent être incorporés. Les chemins externes relatifs ou absolus, URL réseau/file:/data: et résolutions dynamiques non littérales détectées sont refusés. Le registre ne lit, ne charge et n’exécute aucune dépendance pendant cette analyse.

Le contrôle ne suit pas tous les alias, la réflexion ou les chargements créés avec createRequire. Il ne garantit pas la sécurité du module et ne réduit pas ses droits de processus. La revue humaine des sources et dépendances reste nécessaire.

Manifest d’extension#

{
  "id": "agency.example", "name": "Example", "version": "0.1.0",
  "description": "Validation des extraits avant publication.",
  "author": "Agency", "license": "GPL-3.0-or-later",
  "requiresCms": "^0.1.0", "requiresNode": ">=22.12.0",
  "entry": "index.mjs", "permissions": []
}

Les propriétés inconnues sont refusées. Les permissions commencent par l’identifiant du plugin suivi d’un point. dependencies exprime les compatibilités requises entre extensions ; le CMS vérifie leurs versions, l’état actif et les cycles. Le manifest de thème déclare parent et requiresParent, ou null pour un thème racine. Une plage de compatibilité doit correspondre aux versions réellement testées.

Signer avec Ed25519#

mkdir -p .local/signing .local/cms/trusted-publishers
chmod 700 .local/signing .local/cms/trusted-publishers
openssl genpkey -algorithm ED25519 -out .local/signing/private.pem
chmod 600 .local/signing/private.pem
openssl pkey -in .local/signing/private.pem -pubout -out .local/cms/trusted-publishers/local.publisher.pem
pnpm cms plugin:pack extensions/official/directory/dist .local/directory-signed.cms-plugin local.publisher .local/signing/private.pem

Cet exemple suppose de nouveaux fichiers et CMS_DATA_DIR=.local/cms. Ne l’exécutez pas sur une clé existante. L’exploitant approuve et installe lui-même la clé publique. Une clé incluse dans un package ne devient jamais approuvée automatiquement.

Packs initiaux et catalogues de langue#

pnpm package:starter-packs produit Business, Directory, Catalog, Membership et Developer dans un nouveau dossier, avec la clé d’un éditeur approuvé. Le script reconstruit le dépôt avant ses imports et signatures, puis revérifie son état Git. Chaque archive signe sa composition et les packages embarqués ; un catalogue et les empreintes permettent d’en contrôler la provenance. Une capture non destinée à la publication exige --development-snapshot.

pack:sign et pack:import préparent les compositions sélectionnables pendant l’assistant initial. L’enveloppe et les modules exigent des signatures valides et un éditeur déjà approuvé, sans --allow-unverified. La sélection lie identifiant, version et empreinte et les revérifie à l’installation. Ces packs ne fournissent pas encore un catalogue central de téléchargement ni un parcours d’application à un site existant.

language:sign produit un catalogue .cms-language ; l’administration et language:import contrôlent signature, compatibilité et messages avant activation. L’historique permet le retour à une version compatible. La préférence de compte reste indépendante de la langue du site et ne traduit aucun contenu client. Consultez le guide des langues.

Intégrité et immutabilité#

La signature couvre le manifest normalisé et l’empreinte du module. Les fichiers installés sont stockés par empreinte et vérifiés avant chargement. L’installation seule n’exécute pas le code ; activation, aperçu et certains contrôles de mise à jour peuvent le charger.