Skip to main content
Un pack se compose de trois fichiers joints à une release GitHub. failproofai pack build génère ces trois fichiers à partir d’un fichier de politiques existant.

​
1. Écrire les politiques

Un seul fichier, utilisant la même API que n’importe quelle politique personnalisée. Deux champs supplémentaires sont importants pour un pack :
defaultEnabled vaut false par défaut si vous l’omettez. Un simple failproofai pack add n’active que ce que vous avez marqué — activer silencieusement toutes les politiques d’un inconnu est une décision que l’installateur ne devrait pas prendre à la place de l’utilisateur.
L’entrée doit être un fichier unique et autonome. Seule l’entrée est épinglée par son condensé, donc un pack qui importe des fichiers locaux ne pourrait pas honnêtement prétendre que le condensé couvre ce qui s’exécute. Regroupez d’abord vos sources (esbuild, bun build, rollup) et construisez le pack à partir du bundle — pack build refuse une importation locale plutôt que de livrer une promesse qu’il ne peut pas tenir.

​
2. Construire les fichiers de release

Cette commande génère trois fichiers et valide chaque politique avec les règles propres au chargeur en premier — ainsi, un pack qui ne pourrait jamais s’installer échoue ici, là où vous pouvez corriger le problème : Refusé à la construction : un id qui n’est pas au format publisher/name, un nom de politique contenant /, une politique déclarant alwaysOn, une description, une category ou un match manquant, une entrée qui n’enregistre rien, et une entrée qui importe des fichiers locaux.

​
3. Joindre les fichiers à une release

Étiquetez la release avec la même version que celle utilisée lors de la construction, et joignez les trois fichiers en tant qu’assets de release :
N’importe qui peut désormais l’installer :
Les noms des assets sont fixes — c’est à partir d’eux que le CLI consommateur construit ses URLs, sans appel API ni découverte automatique.

​
Publier une nouvelle version

Construisez avec le nouveau --version, créez une nouvelle release, joignez à nouveau les trois assets. Les utilisateurs exécutent le même pack add et conservent le sous-ensemble de politiques qu’ils avaient choisi ; une politique qu’ils avaient désactivée reste désactivée après la mise à jour. Changer le nom d’une politique est un changement cassant : une machine qui l’avait désactivée désactive un nom qui n’existe plus, et le nouveau nom arrive avec ce que defaultEnabled indique.

​
Ce à quoi vos utilisateurs font confiance

SHA256SUMS réside dans la même release que l’artefact, ce qui prouve que les octets sont bien ceux que vous avez publiés — pas votre identité. Quiconque peut écrire dans le dépôt peut modifier les deux fichiers. La protection des utilisateurs tient au fait que le condensé est épinglé lors de l’installation, de sorte que ce que vous avez publié ne peut pas changer sous leurs pieds par la suite. Publiez depuis un dépôt dont vous contrôlez les accès en écriture, et traitez une release de pack comme la publication d’un package.

​
Observer avant d’appliquer

Un manifeste peut déclarer "effect": "observe". Ces politiques s’exécutent et leurs verdicts sont enregistrés puis ignorés — rien n’est bloqué. C’est la façon de mesurer une nouvelle règle sur du trafic réel avant qu’elle ne puisse interrompre le travail de quiconque.