Coontext is currently in pre-1.0 development. Only the latest release on the main branch receives security updates. There is no LTS branch.

Once the project reaches 1.0.0 this table will be updated to reflect a proper support window.

Please do not open public GitHub issues for security vulnerabilities.

If you believe you have found a security vulnerability in Coontext, report it privately via one of these channels:

1. GitHub private security advisory (preferred) — open a draft advisory. This routes directly to the maintainers and creates a private discussion thread.
2. Email — adriandomc@gmail.com with the subject line [coontext-security] <short title>. PGP encryption is welcome but not required.

When reporting, please include:

• A clear description of the vulnerability and its impact.
• Steps to reproduce, ideally with a minimal proof of concept.
• The version (or commit hash) of Coontext you tested against.
• Your operating system and version.
• Whether you intend to disclose the issue publicly, and on what timeline.

We follow a coordinated disclosure model. Reporters are credited in the release notes (and the security advisory) unless they prefer to remain anonymous.

In scope:

• The Coontext binary and its source code in this repository.
• The build, release, and CI workflows under .github/workflows/.
• Any first-party scripts under scripts/.

Out of scope:

• Third-party dependencies (please report those upstream — we use cargo-audit and cargo-deny to track them via RustSec).
• The Rust toolchain itself, GitHub Actions runners, or other infrastructure Coontext relies on.
• Vulnerabilities that require attacker-controlled local code execution to begin with (we assume the user trusts the binary they ran).
• Issues affecting forks or modifications of Coontext that aren't present in the upstream code.

The following protections are baked into the codebase and verified by CI:

• No telemetry / no network access — Coontext is fully offline. The binary makes no outbound connections, has no analytics SDK, and has no crash-reporting service. Telemetry crates (sentry, sentry-core, rollbar, bugsnag) are banned at the supply-chain level via cargo-deny.
• Filename sanitization — normalize_filename rejects path traversal (., .., leading .), control characters, Unicode bidi-override characters (the Trojan Source attack class), trailing dots, and Windows reserved names.
• Markdown rewrite safety — rename_file walks markdown via pulldown_cmark's offset iterator and only rewrites image references outside fenced code blocks and inline code spans, so user content inside code blocks is preserved verbatim.
• Secure temp directories — screenshot temp files go through tempfile::Builder::new().tempdir(), which uses mkdtemp(3) (mode 0700 on Unix) — not the world-readable std::env::temp_dir().
• Corrupt-config recovery — if config.json or recent.json fails to parse, it's renamed to .bak and defaults are used instead of silently overwriting the user's settings.
• Static application security testing — every push and PR runs:
  • cargo-audit (RustSec advisory DB)
  • cargo-deny (licenses, bans, sources)
  • OSV-Scanner (Google's OSV DB, additional CVE coverage)
  • CodeQL (static analysis for the project's language set)
  • cargo clippy --all-targets -- -D warnings (treats lints as errors)

Security researchers who have responsibly disclosed vulnerabilities are listed here, with their permission:

(none yet — be the first!)