Skip to main content
Ein Pack besteht aus drei Dateien, die an ein GitHub-Release angehängt werden. failproofai pack build erzeugt alle drei aus einer bereits vorhandenen Policy-Datei.

​
1. Die Policies schreiben

Eine Datei, mit derselben API wie jede andere Custom Policy. Zwei zusätzliche Felder sind für ein Pack relevant:
defaultEnabled ist standardmäßig false, wenn es weggelassen wird. Ein einfaches failproofai pack add aktiviert nur die Policies, die du als solche markiert hast — alle Policies eines unbekannten Packs unbeaufsichtigt zu installieren ist eine Entscheidung, die der Installer nicht für seinen Nutzer treffen sollte.
Der Eintrag muss eine in sich geschlossene Datei sein. Nur der Eintrag wird per Digest gesichert, daher könnte ein Pack, das lokale Dateien importiert, nicht ernsthaft behaupten, der Digest decke das ab, was tatsächlich ausgeführt wird. Bündele die Dateien zuerst (esbuild, bun build, rollup) und baue das Pack aus dem Bundle — pack build lehnt einen lokalen Import ab, anstatt ein Versprechen zu liefern, das es nicht einhalten kann.

​
2. Die Release-Assets bauen

Der Befehl schreibt drei Dateien und validiert jede Policy zunächst mit den eigenen Regeln des Loaders — damit schlägt ein Pack, das sich nie installieren ließe, hier fehl, wo du es noch beheben kannst: Beim Build abgelehnt werden: eine ID, die nicht dem Format publisher/name entspricht, ein Policy-Name mit /, eine Policy, die alwaysOn deklariert, eine fehlende description, category oder match, ein Eintrag, der nichts registriert, und ein Eintrag, der lokale Dateien importiert.

​
3. An ein Release anhängen

Tagge das Release mit derselben Version, die du beim Build angegeben hast, und füge alle drei Dateien als Release-Assets hinzu:
Jetzt kann jeder das Pack installieren:
Die Asset-Namen sind fest vorgegeben — aus ihnen baut die CLI des Consumers die URLs, ohne API-Aufruf und ohne Erkennung.

​
Eine neue Version veröffentlichen

Baue mit der neuen --version, tagge ein neues Release und hänge die drei Assets erneut an. Consumers führen dasselbe pack add aus und behalten die Auswahl, die sie getroffen hatten; eine deaktivierte Policy bleibt auch nach dem Upgrade deaktiviert. Den Namen einer Policy zu ändern ist ein Breaking Change: Eine Maschine, die ihn deaktiviert hatte, deaktiviert nun einen Namen, der nicht mehr existiert — und der neue Name wird mit dem Wert aus defaultEnabled aktiviert.

​
Was deine Nutzer vertrauen

SHA256SUMS liegt im selben Release wie das Artefakt und beweist damit, dass die Bytes genau die sind, die du veröffentlicht hast — nicht wer du bist. Wer Schreibzugriff auf das Repository hat, kann beide Dateien schreiben. Der Schutz für deine Nutzer besteht darin, dass der Digest beim Installieren fest eingespeichert wird — was du geliefert hast, kann sich danach nicht mehr unter ihnen ändern. Veröffentliche aus einem Repository, dessen Schreibzugriff du kontrollierst, und behandle ein Pack-Release wie die Veröffentlichung eines Pakets.

​
Beobachten, bevor du durchsetzt

Ein Manifest kann "effect": "observe" deklarieren. Diese Policies laufen, und ihre Urteile werden aufgezeichnet und verworfen — es wird nichts blockiert. Das ist der Weg, eine neue Regel gegen echten Traffic zu messen, bevor sie die Arbeit von jemandem unterbrechen kann.