Aisixteen Fantastic (fantastic-canvas) is pre-1.0 (alpha). Security fixes land on the latest release line only; older tags are not maintained.

Please do not open a public issue, PR, or discussion for a security problem.

Use GitHub's private vulnerability reporting: open the repository's Security tab → Report a vulnerability. That creates a private advisory visible only to the maintainers, where we can triage and coordinate a fix and disclosure with you.

Helpful to include, where you can:

• the affected runtime(s) — python/, rust/, or the ts/ frontend — and a version or commit SHA;
• a description, impact, and a minimal reproduction;
• whether it touches the protocol surface (the HTTP/WS/REST wire shapes, system verbs, the reflect contract, or the on-disk .fantastic/ format) — those affect every host runtime, so they're higher severity.

This is a best-effort alpha project: we aim to acknowledge within a few business days and will agree a remediation + disclosure timeline with the reporter.

Every GitHub Release carries SHA256SUMS (the CLI archives) and, from the desktop app's first signed release, SHA256SUMS-app (its installers). CI builds and tests the installers; the maintainer signs them by hand, and no signing key is stored on GitHub. They are signed:

• macOS — the DMG and the app are signed with a Developer ID Application certificate, notarized and stapled: spctl -a -vvv -t open --context context:primary-signature fantastic-app-aarch64-apple-darwin.dmg must print source=Notarized Developer ID.

• Windows — the setup, fantastic-app.exe and fantastic.exe carry a timestamped Authenticode signature: Get-AuthenticodeSignature .\fantastic-app-x86_64-pc-windows-msvc-setup.exe must report Valid.

• Linux — the .deb has a detached, armored GPG signature (<file>.asc): gpg --import fantastic-app-linux-signing-key.asc && gpg --verify fantastic-app-x86_64-unknown-linux-gnu.deb.asc fantastic-app-x86_64-unknown-linux-gnu.deb must report a good signature by the key whose fingerprint is listed here:

  • Linux signing key fingerprint: (added by the maintainer when the key exists, as Linux signing key fingerprint: `<40 hex, no spaces>`; installers.yml -f check=vX.Y.Z reads it from this line)

Fantastic is a single-operator system: one user's fleet of kernels that mutually trust each other. It is not multi-tenant and does not try to isolate untrusted callers from each other.

Consequently the kernels' control surfaces — HTTP / WebSocket / REST — are not independently authenticated by design. The trust boundary is the channel / transport: loopback, an SSH-tunnelled or otherwise authenticated broker, or a trusted private network. Anyone who can reach a kernel's control surface can drive it — including stopping it via the shutdown_kernel verb. That is intended; deploy accordingly:

• bind to loopback (-p 127.0.0.1:<port>:<port>) or front the kernel with an authenticated proxy / SSH tunnel;
• treat container kernels as disposable execution units — never bake or persist credentials in the image or in the bind-mounted .fantastic/ workdir; inject scoped, short-lived tokens via env at spawn time;
• the spawning control plane (e.g. the AI chat that launched the kernel) holds the credentials — the kernel does not.

A report that simply states "the WS/REST surface has no auth" describes the documented model, not a vulnerability. Reports that defeat the intended boundary are in scope — for example: path-traversal past a file agent's root, sandbox escape from a view iframe, a crafted payload that crashes or hangs the kernel (DoS), secrets leaking into reflect/logs/.fantastic/, or a weak-load / deserialization flaw in the on-disk format.

In scope: the kernels (python/, rust/), the browser frontend (ts/), the universal container image, and the send/reflect protocol + .fantastic/ on-disk format.

Out of scope: vulnerabilities in third-party dependencies (report upstream; tell us if a fix needs a version bump here), and any separately-licensed managed cloud / relay / sync offering (not part of this repository).