kotiko

Public git repository on GitHub: https://github.com/ScriptKittyOS/kotiko

git records every change with its author and date. https://github.com/ScriptKittyOS/kotiko/commits/main

Every change to main goes through a pull request (a ruleset requires pull requests and eight passing CI checks), and the full history with its interim commits is public, not only releases. https://github.com/ScriptKittyOS/kotiko/pulls?q=is%3Apr

git, hosted on GitHub: https://github.com/ScriptKittyOS/kotiko

Each release has its own SemVer version (0.1.0, 0.2.0, next 1.0.0), kept identical in the server, the extension manifest and the release manifest; CI fails if they differ.

Semantic Versioning; release-please derives versions from Conventional Commits.

Human-readable release notes for every release, written for users, not a git log: https://github.com/ScriptKittyOS/kotiko/blob/main/CHANGELOG.md

No publicly known vulnerability (with a CVE or similar) has been fixed in a release. The one security fix so far (0.2.0, an authentication bypass found by our own review, never public) is still named in the 0.2.0 notes. Future notes list every advisory and CVE (SECURITY.md, What happens after you report, step 6).

Bugs are reported as GitHub issues, with forms for bugs, broken sites and wrong words: https://github.com/ScriptKittyOS/kotiko/issues/new/choose

GitHub Issues, with forms for bugs, ideas, broken sites and wrong words: https://github.com/ScriptKittyOS/kotiko/issues

No bug reports have been submitted yet (the repository opened on 2026-10-06). Maintainers take a weekly triage turn: every new issue gets a label and a first response within 7 days (GOVERNANCE.md).

No enhancement requests have been submitted yet; the same 7-day triage applies to them (GOVERNANCE.md).

GitHub Issues keeps every report and reply, searchable: https://github.com/ScriptKittyOS/kotiko/issues?q=is%3Aissue

https://github.com/ScriptKittyOS/kotiko/blob/main/SECURITY.md

Report privately through GitHub's private vulnerability reporting (https://github.com/ScriptKittyOS/kotiko/security/advisories/new) or by email to security@scriptkittyos.com, as SECURITY.md says: https://github.com/ScriptKittyOS/kotiko/blob/main/SECURITY.md

No vulnerability reports have been received in the last 6 months. SECURITY.md commits to acknowledging within 7 days.

The server is built with Mix (mix compile, run by server/run.sh); dependencies are pinned in mix.lock. The extension ships as written, with no bundler; scripts/build-extension.mjs packs it into reproducible zips for each browser.

Mix (Elixir's standard build tool) and npm for development tools.

Elixir, Erlang/OTP, Mix, Node.js and npm are all FLOSS.

ExUnit tests for the server, Node's built-in test runner for the extension (unit, DOM and background suites) and Playwright end-to-end tests, all in the repository under Apache-2.0. How to run them: CONTRIBUTING.md, Setup; CI runs them on every pull request.

npm test (Node's built-in test runner) for the extension and mix test for the server, the standard commands of each ecosystem; npm run e2e runs the Playwright end-to-end tests. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#setup

Measured 2026-10-06 and enforced in CI: the server's tests cover 91.6 % of lines (mix test --cover, which fails below 90 %), and the extension's tests 93.9 % of lines and 84.5 % of branches (npm run coverage, which fails below 90 % of lines or 80 % of branches).

Every change reaches main through a short-lived pull request, and GitHub Actions runs every test suite, the linters and the audits on each pull request and each push to main; main requires 8 checks to pass. https://github.com/ScriptKittyOS/kotiko/actions/workflows/ci.yml

Every pull request that adds or changes behaviour adds or updates automated tests in the same pull request; every bug fix adds a regression test (CONTRIBUTING.md, Tests).

The most recent major features came with tests, for example backup, restore, export and delete (commit c5144de: server, background, DOM and end-to-end tests), the accessibility baseline (59af37e: axe and screen-reader end-to-end tests) and the docs site (97e2943: build and page tests).

The instructions for change proposals say it: CONTRIBUTING.md, Tests (https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#tests), requires tests with every behaviour change and says major new functionality is not merged without them, and the pull request template's checklist asks for them.

The server compiles with warnings as errors on the oldest and newest supported Elixir; Credo, ESLint (with eslint-plugin-no-unsanitized), web-ext lint and ShellCheck run in CI.

CI fails on any compiler warning and any Credo, ESLint or ShellCheck finding. web-ext lint reports one known warning on the source manifest: Firefox ignores the Chrome service-worker key, which is intended (the source lists both forms; the Firefox package is built without it).

Warnings are as strict as practical, and any warning fails CI on every pull request: the server compiles and runs its tests with --warnings-as-errors; Credo runs in strict mode (server/.credo.exs sets strict: true, so a plain mix credo reports the same); ESLint adds about 60 rules beyond its recommended set (among them eqeqeq, no-shadow, no-unused-vars for every argument, no-param-reassign, no-implicit-coercion, no-loop-func, prefer-const, no-var, no-eval) and treats unused disable directives as errors; web-ext lint, ShellCheck and Sobelow fail on findings too. The few rules not enabled, and why, are written down. https://github.com/ScriptKittyOS/kotiko/blob/main/docs/CODING_STANDARDS.md

The lead maintainer applies the Saltzer and Schroeder principles plus limited attack surface and allowlist input validation; how each is applied is written down in docs/security/assurance-case.md section 4 (for example deny-by-default authentication, loopback bind, one auth plug before routing).

The common weaknesses for this kind of software and how each is countered (XSS, SQL injection, command injection, path traversal, missing authentication, CSRF, SSRF, unsafe deserialization, resource exhaustion, hard-coded credentials, secrets in logs, DNS rebinding, supply chain) are listed in docs/security/assurance-case.md section 5; the adversarial review in docs/research/06-adversarial-qa.md drove the fixes.

Kotiko implements no cryptography. It relies on TLS (Erlang/OTP's ssl for the server's outbound requests, the browser for the extension), SHA-256, PKCE with S256 (RFC 7636) for connecting OpenRouter, and the operating system's and browser's secure random sources.

Only library calls: Erlang :crypto, Plug.Crypto.secure_compare, OTP ssl, and the browser's Web Crypto API.

Erlang/OTP (crypto and ssl, built on OpenSSL) and the Web Crypto API (implemented by Firefox and Chromium) are FLOSS.

By default Kotiko's secrets are 256-bit: the server generates the API token from 32 random bytes. A token the person sets themselves must be at least 24 characters, and the server suggests openssl rand -hex 24 (192 bits). Hashes are SHA-256. TLS key exchange and lengths are left to Erlang/OTP's and the browser's defaults; Kotiko offers no setting that weakens them.

No MD4, MD5, DES, RC4, ECB or disabled certificate checks in Kotiko's code.

No default security mechanism depends on a weak algorithm or mode: there is no SHA-1, MD4, MD5, RC4, DES, ECB or disabled certificate check in Kotiko's code. SHA-256 is used where a hash is needed (lookup cache keys, the PKCE challenge), and TLS is left to Erlang/OTP and the browser.

Kotiko negotiates no keys itself. Its TLS connections use Erlang/OTP (TLS 1.3 and 1.2 by default from OTP 26, the oldest supported) and the browser, which use forward-secret key exchange (TLS 1.3 always; ECDHE for TLS 1.2).

Kotiko has no user passwords. The server is protected by one random API token (bearer token) and compares it in constant time; there are no user accounts.

Tokens, ids, salts and nonces come from cryptographically secure generators: :crypto.strong_rand_bytes on the server, crypto.getRandomValues and crypto.randomUUID in the extension (including the PKCE verifier). Math.random is used only for non-secret values (instance labels, confetti).

The source is delivered from GitHub over HTTPS (git over HTTPS or SSH). The release pipeline publishes each release on GitHub with SHA256SUMS and Sigstore build provenance, and the stores (Chrome Web Store, addons.mozilla.org) sign and deliver their packages over HTTPS.

No hashes are published or fetched over HTTP: SHA256SUMS is a GitHub release file served over HTTPS and covered by the release's attestation.

No unpatched vulnerability of medium or higher severity has been publicly known for more than 60 days, in the code Kotiko ships or in its development tools. mix deps.audit and mix hex.audit run on every pull request, and Dependabot alerts are on. The extension has no runtime npm dependencies; the open Dependabot advisories are all in development tools that never ship, the oldest published on 2026-09-03.

Critical issues are fixed fast. An authentication bypass through encoded paths was fixed the day our own review found it (commit 2693809, 2026-10-01) and has regression tests. The one critical advisory in a dependency, shell-quote in a development tool that never ships (GHSA-pqg4-j6r4-53mv, published 2026-10-06), was patched the same day in pull request #9.

No valid credentials are in the repository or its history. CI runs gitleaks over the full history on every pull request, and GitHub secret scanning with push protection is on.

Credo (Elixir), ESLint with eslint-plugin-no-unsanitized and web-ext lint (JavaScript and the extension), ShellCheck (shell) and gitleaks (secrets) run on every push and pull request, so on every release candidate, and main accepts only pull requests that pass them.

Two security analysers look for common vulnerabilities on every pull request and push to main, and a finding fails the build: Sobelow for the Elixir server (injection, traversal, unsafe deserialization, atom exhaustion; every finding fails, false positives are skipped per function with a written reason) and CodeQL with the security-extended queries for JavaScript and the GitHub Actions workflows (a required check). For the extension, eslint-plugin-no-unsanitized and a ban on HTML string sinks cover DOM cross-site scripting. The policy says what blocks a merge or a release: https://github.com/ScriptKittyOS/kotiko/blob/main/docs/security/dependency-and-static-analysis-policy.md

No static analysis finding is open: CI fails on any, and pull requests are merged only when CI passes. None so far was an exploitable vulnerability.

On every push to main and every pull request.

Property-based testing is the dynamic analysis, and it runs on every pull request and again in the release workflow before anything is built. The extension's pure code (the page matcher, URL checks, bulk-add parsing, backup read and restore, casing, the word-list check) is tested with fast-check, and the server's request validation, word spec, settings parsing, language tags, text cleaning, redaction and backup round trips with StreamData; each run uses a new seed, and a failing seed can be replayed. It has found real defects: a word with Å or Ņ made the server answer 500, a repeated query parameter did the same, and a re-add brought back a form the learner had removed; each was fixed with a regression test. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#tests

Kotiko's code is Elixir and JavaScript, both memory-safe. The only memory-unsafe code is SQLite inside a dependency (exqlite), which the project does not write or build itself.

Under test, the extension runs with an assertion mode (globalThis.KOTIKO_ASSERT, set only by the test harness and never by the shipped extension): the matcher checks every scan's matches (bounds, text, order, no overlap), the backup restore plan checks its counts and that it never writes a deleted word, and the word-list check verifies every word is kept or counted. The property-based tests drive these paths with generated input. The server relies on Elixir's pattern matches and guards, which already stop on a broken invariant in production. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#tests

Every defect the property-based tests have found was fixed in the same change, with a regression test: two inputs that made the server answer 500 (a word with Å or Ņ, and a repeated query parameter) and a merge rule that brought back a removed form. None was an exploitable vulnerability. Any medium or higher vulnerability they find is fixed within the deadlines in SECURITY.md. https://github.com/ScriptKittyOS/kotiko/blob/main/SECURITY.md