Please do not open a public GitHub issue for security vulnerabilities.

Instead, report them privately through GitHub's private vulnerability reporting ("Report a vulnerability" under the repository's Security tab). If that is unavailable to you, email the maintainer.

When reporting, please include:

• A description of the issue and its impact
• Steps to reproduce (a minimal proof of concept is ideal)
• The affected version or commit
• Any suggested remediation, if you have one

You can expect an acknowledgement within a few days. We'll work with you on a fix and coordinate disclosure once a patch is available.

Interlace's first surface, lace, is a local, single-user developer CLI. The operator is trusted; the data sources it indexes are not necessarily so. The most relevant boundaries:

• Untrusted repositories. A project-local .interlace.toml is treated as untrusted — it may only set non-sensitive settings (defer_token, ranking). Credentials and connection targets (DATABASE_URL, GITHUB_TOKEN, INTERLACE_TOKEN, REDIS_URL) are read only from trusted layers (command flags, environment, and ~/.config/interlace/).
• File writes (lace close) are confined to the registered project root.
• No untrusted code execution. Collectors shell out only to fixed binaries (rg, git) with argument arrays — never through a shell — and never evaluate repository content.

Reports that depend on the operator deliberately attacking their own machine (e.g. passing a malicious path on their own command line) are generally out of scope, but we're still happy to harden against surprising behavior.

Interlace is pre-1.0 and under active development. Security fixes are applied to the main branch.