Policy

What we check before publishing

A plugin runs with the permissions of whoever installs it. That's why review isn't a style check: it is the condition for entering the catalogue, and every stage in it is verifiable.

The pipeline

passedfindingsblockednot configured

These run in order on every submitted version. A stage that isn't configured is skipped without blocking the pipeline, and says so in the record published with the plugin.

01
Archive verification
The SHA-256 digest must match the one recorded at submission time.
02
Manifest validation
Package format, and declared permissions checked against the components actually present.
03
Automated rules
AST analysis for JavaScript and TypeScript, textual analysis for Python and shell.
04
Dependencies
Exact pinning, remote sources, install scripts.
05
Malware scannernot configured
Digest lookup against VirusTotal.
06
Sandbox dry run
Isolated container with no network, read-only filesystem, capabilities dropped.
07
Semantic AI reviewnot configured
What the code actually does, compared against what was declared.
08
Human review
Every ambiguous or high-risk case goes past a person before publication.

Mandatory rules

A single critical violation rejects the version outright. Medium and high findings go to a person.

No dynamic code executionsecurity/no-dynamic-eval

eval(), new Function(), the vm module, exec() and eval() in Python, eval in a shell. Code that assembles itself at runtime can't be reviewed, so it can't be published.

No encoded payloadssecurity/no-encoded-payload

Base64, hex or rot13 strings that get decoded and executed. Decoding and execution in the same expression is an automatic rejection.

No obfuscationsecurity/no-obfuscation

Single-line minified sources, unusual density of hex escapes, identifiers produced by an obfuscator. Distributed code has to stay readable.

Dependencies pinned to exact versionsdeps/unpinned

No ranges, no git or http references. What the user installs must match what was reviewed, not whatever the registry serves today.

Network access only when declaredsecurity/no-undeclared-network

In the “local only” tier any outbound traffic is a rejection. In the “declared network” tier every domain contacted must appear in the declaration, which the user sees before installing.

No listening portssecurity/no-open-ports

A plugin does not expose services on the machine of whoever installs it.

No downloading of executable codesecurity/no-remote-code-fetch

curl piped into a shell, npx against remote URLs, pip install from git. Prohibited in every tier, because the code that runs wouldn't be the code that was reviewed.

Filesystem within scopesecurity/filesystem-scope

No recursive deletion of system paths, no reading of ~/.ssh, cloud credentials or .env files.

After publication

Review doesn't stop at the listing

Every plugin listing has a report form. A well-founded report suspends the listing immediately: the plugin disappears from the catalogue and from the manifests we serve — including for future installs — while the check is under way.

Browse the catalogue