Threat model¶

Status: written for 0.0.24 (workstream 9), read against the code on the 0.0.24 branch. It is the starting point of the structured security review in stage 4 of the plan to 1.0.0, which works through the checklist at the end. Reporting a vulnerability is covered by SECURITY.md.

Most of rs-rich is a rendering library: it turns text into terminal output and has no more authority than the program that calls it. This page covers the parts that do more. They run code someone else wrote, take files and signatures from the network, serve a network, drive a browser or start other programs:

1. Plugins: native libraries and WASM modules.
2. The marketplace: the signed index, the key chain, installs, the lockfile and the signing workflow.
3. rich serve and rs-rich-web.
4. Noctiluca and Chrome.
5. rs-rich-embed's PTY host.
6. TLS, certificates and redirects.
7. ACP agents for Cornacai (designed, not built yet).
8. The log console: rich console and an intuiTUIve app's events on a local socket.

How to read this page¶

Each surface has the same parts:

• Assets: what an attacker wants.
• Trust boundaries: where data or control passes from a less trusted party to a more trusted one.
• Entry points: where the less trusted side's input arrives.
• Threats, in a table. The letter is the STRIDE category: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Each threat names its mitigation, linked to where it is implemented or documented, and its state:
• verified: read in the code for this page (not yet checked against tests: that is stage 4's work);
• documented: the docs say so, and the code was not read closely enough to confirm it;
• unverified: neither could be confirmed;
• gap: no mitigation, or only a partial one;
• mitigated: a gap the 0.0.24 hardening round closed, linked to the fix and its test;
• planned: the feature is designed but not built.
• Gaps: what the review should decide on: fix, accept or record.

Code links point at main and name a file, not a line, so they do not go stale; the review reads the code at the release candidate.

Who the attackers are¶

Out of scope: an attacker who already runs code as the user, owns the user's account or the maintainer's GitHub account, or holds both marketplace keys. Bugs in Chrome, the terminal emulator, the operating system's PTY or the Rust toolchain belong to those projects, though the review notes where rs-rich makes one easier to reach.

Cross-cutting mitigations¶

These apply to more than one surface, and the sections below refer to them.

• Terminal output from untrusted input is sanitized. Plugin output, page text in Noctiluca, rich view, rich diff, rich log and the schema view make every control character visible (rich_ext::sanitize, noctiluca::clean). Upstream's rendering commands (rich FILE, rich URL, --markdown and the rest) keep upstream's output, so they pass terminal controls through unless --sanitize is given (see section 6).
• A project's config is untrusted. A ./rich.toml in the working directory may not load plugins, name a theme file, choose files to write, turn sanitizing off, start a browser (mermaid_backend = "mmdc"), run Graphviz or trust its own micro assets; each such key is dropped with a note (config.rs, UNTRUSTED_*; PLUGINS). verified.
• Parsers of outside input are fuzzed nightly: markup, ANSI, Markdown, DOT, Mermaid, CSV, JSON, JSONL, stylesheets, the VT emulator, tapes, WebSocket frames and the page's input, the plugin manifest and WASM loading, and the marketplace's documents, signatures and artifacts (fuzzing).
• Network features are opt-in at build time. rich serve is behind the CLI's off-by-default serve feature, native plugins behind dylib-plugins, and URL fetching behind fetch.

1. Plugins: dylib and WASM¶

Documented in PLUGINS: Security and the plugin-loading design. Code: rich-ext/src/plugin_loading/ and rich-plugin-api/src/abi.rs.

Assets: the user's account (files, credentials, network) for a native plugin; the integrity of what the terminal shows, and the terminal itself, for every plugin; the rich process's availability.

Trust boundaries:

• the rich process and a native library loaded into it (none in practice: the library runs as the process);
• the host and a WASM instance (the wasmi interpreter);
• a plugin's output and the user's terminal.

Entry points: --plugin PATH; plugins = [...] in the user's config or a --config file; packages installed with rich plugin install; the manifest a module returns; every call's output (text, highlighter spans, fence output, markup).

Gaps:

• A WASM plugin still decides what the user reads. A transform or highlighter can change or hide text within its output budget: the sandbox keeps it from the system, not from lying about content. The review should decide whether output shown from a community plugin is marked as such.
• Time per render is bounded only per call. A page with many fences calls a plugin once per fence, each with its own 50 million units of fuel; there is no budget per render or per process. gap (availability).
• Load-time cost. Validation and wasmi's translation of a 16 MiB module are not fuel-metered. unverified whether translation is lazy and metered.
• Native plugins in the Python package and other hosts. Whether every host that enables dylib-plugins (the Python bindings included) keeps the same "only a path the user chose" rule. unverified.

2. The marketplace and its signer¶

Documented in the listing format: Signing and Key rotation, the Marketplace page and PLUGINS: the marketplace client. Code: crates/rich-marketplace, the CLI's marketplace.rs, and the marketplace repository's workflows, kept in docs/marketplace-repo/.

Assets: the main and backup signing keys; the deploy key (moving to a GitHub App in workstream 8); the integrity of index.json, every listing and every artifact; the user's install directory (its lockfile, its state file and the installed files); which packages a user believes are official.

Trust boundaries:

• a listing pull request (anyone) and main of the marketplace repository (a maintainer's merge);
• main and the signing job in the protected marketplace-signing environment (a required reviewer);
• the signing job and third-party code it runs (actions, pip and apt packages, rs-rich-cli's validator at RS_RICH_CLI_REF);
• the network (index, listings, key generations, artifacts on any HTTPS host) and the client;
• the install directory on disk and each later run that loads from it.

Entry points: index.json and index.json.minisig; keys/keys-N.json and their signatures; packages/ID.json; artifact URLs; --marketplace, RICH_MARKETPLACE, --marketplace-keys, RICH_MARKETPLACE_KEYS, --plugin-dir, RICH_PLUGIN_DIR; marketplace.lock.json and marketplace.state.json.

Gaps:

• Supply chain of the signing job. Its actions were pinned by tag, not by commit; jsonschema was installed from PyPI unpinned, in the same job that later receives the key; the validator was fetched from rs-rich-cli at RS_RICH_CLI_REF, main unless the variable was set. Now every action in sign-index.yml is pinned to a full commit SHA, jsonschema and its dependencies are installed only from requirements-signer.txt with --require-hashes, and RS_RICH_CLI_REF defaults to the commit of rs-rich-cli's release-0.0.23 tag (check-listings.yml too). Applies once the marketplace repository takes the change. mitigated (0.0.24). Left: minisign still comes from Ubuntu's signed apt archive, and the other marketplace workflows (no signing secrets) still pin actions by tag.
• Revocation needs the client to see the next generation. Key generations are fetched from the same location as the index. A client pointed at a location that withholds keys-N+1.json (a stale mirror, a RICH_MARKETPLACE the attacker chose) kept trusting a revoked main key, even when another location had already shown it the revocation, because the walk's starting point was kept per location. It is now kept per trust root, so once any location has served a revoking generation, an index signed by the revoked key is refused everywhere, with an error saying the location is stale or withholding keys (marketplace.rs, open, stale_keys_hint; tested in plugin_marketplace.rs). mitigated (0.0.24) for a client that has seen the revocation. Left, by design: a client that never has depends on the compiled-in generation, so a revocation is followed by a release that compiles in the new one. A signed "current generation" field in the index was considered and not added: the index is signed by the main key, so a holder of a leaked main key could write any value there.
• The state file was a trust anchor. marketplace.state.json cached the newest verified key generation as a key set, read back without re-verification and checked only against the root's main key id, and the install directory was made with the default permissions (umask). The state now keeps the generations as their keys-N.json files and signatures, verified again from the trust root (compiled in, or the one named) whenever they are read; a chain that does not verify is dropped with a warning, so the file can take the walk back to the root but never add a key. A 0.0.23 cached key set is not read. Directories the marketplace creates are mode 700 on Unix (create_private_dir_all). Same links as above. mitigated (0.0.24). Write access to the install directory still lets someone change what is installed, as the lockfile's entry below says.
• RICH_MARKETPLACE_KEYS and --marketplace-keys replace the trust root with any file. That is their purpose; an environment variable is, however, easy to set in a shared shell profile or CI. Consider a warning whenever the root is not the compiled-in one. gap (low).
• Micro packs are checked at registry load, then read by path when their images are drawn, so a file swapped after the check is read unchecked. Low: it needs write access to the install directory. gap.
• The move to a GitHub App (workstream 8) changes who can push to the marketplace's main; the review covers the App's permissions and key storage. planned.

3. rich serve and rs-rich-web¶

Documented in Serving an app to a browser: Security. Code: crates/rich-web/src (server.rs, http.rs, isolate.rs, pty.rs, session.rs) and the CLI's serve.rs.

Assets: whatever the served app or program can do: for rich serve -- bash, a shell as the user. The token. The server's availability. The browser's clipboard.

Trust boundaries:

• the network (or other local users) and the HTTP server;
• any web page in the user's browser and the server's WebSocket on a loopback port;
• the server and each session's process (Unix: its process group; Windows: a job object);
• a served program's output and the page (xterm.js).

Entry points: the HTTP request line and headers (Host, Origin, the token, cols, rows, renderer parameters); WebSocket frames (keys, pastes, mouse, resizes, acknowledgements); the loopback port each session's process connects back to; RS_RICH_WEB_SESSION.

Gaps:

• No TLS, and the token travels in the URL. It is in the printed address, the browser's history and any proxy's access log, and lasts as long as the server. Behind a reverse proxy, the proxy's logs need care. Consider moving the token to a cookie or the first WebSocket message after the page loads. gap (documented as "use a proxy with TLS").
• Bound to all interfaces, any Host was accepted as long as the origin matched it, so DNS rebinding was stopped by the token alone. The server now keeps a Host allow-list there too: the loopback addresses, localhost, the machine's name (and NAME.local), the address each connection arrived on, and names given with Server::allow_host (rich serve --allow-host) (http.rs, allowed_hosts, connection_hosts; tested in serve.rs). mitigated (0.0.24).
• Session processes inherit the server's whole environment, secrets included; a served program can read them. Document it, or offer an allow-list. gap (low).
• xterm.js's handling of links (OSC 8) and other OSC strings in a served program's output: what the vendored xterm.js 6.0.0 does when one is clicked. unverified.
• Resource caps on Windows (memory and CPU) are Unix-only. gap (documented).

4. Noctiluca and Chrome¶

Documented in Privacy and security and the browser design: Security. Code: crates/noctiluca/src (cdp.rs, clean.rs, url.rs) and rs-rich-embed's chrome.rs.

Assets: the browser profile (cookies, storage, history), above all a kept one with signed-in sessions; local files reachable as file://; the user's terminal; what the user believes about a page (its real host, which link goes where); the DevTools channel, which controls the whole browser.

Trust boundaries:

• a web page (inside Chrome's sandbox) and Noctiluca's process: everything the page says arrives as DevTools JSON;
• Noctiluca and the user's terminal;
• other local processes and users and the DevTools endpoint;
• an agent or script and the control socket (#816, --control), and other local users and that socket;
• with --ssh HOST: this machine and the SSH server, which carries every request; and other local users and the tunnel's loopback port.

Entry points: DOM snapshots and accessibility trees; titles, URLs, link targets, alt text, option labels, dialog text, download names; the bookmarks file; DevTools events (Runtime.bindingCalled, Browser.downloadWillBegin); the address bar; Chrome's switches; --chrome and RICH_EMBED_CHROME; --ssh HOST, --ssh-arg and what ssh writes on standard error; the control socket's requests; the screencast's pixels in the pixel view.

Gaps:

• Extra Chrome switches. Only sandbox and DevTools switches are filtered. A caller of ChromeEngine::args can still pass switches that weaken the browser in other ways (--disable-web-security, --allow-file-access-from-files, --remote-allow-origins, --load-extension). Noctiluca passes none today. Decide whether the filter becomes an allow-list. gap (low).
• Downloads by quarantine are designed (ask first, a cleaned name, never run) but not wired into Noctiluca; when they are, the review covers the quarantine's location, its permissions and the move. planned.
• The agent-control CLI (#816): in, with the rows above. What is left:
• Windows has no control socket yet (a named pipe with an ACL for the user): the commands say "Unix only for now". gap (low).
• Page text reaches the agent. A snapshot is the page's own text, cleaned of control characters but not of meaning, so a page can write instructions aimed at an agent. The agent must treat it as data. With a kept profile, a session that is not read-only lets an agent act signed in; Noctiluca prints a note when both are on. gap (medium): consider refusing control with a kept profile unless the user says so.
• Repudiation. Every action shows in the status bar as it happens, but nothing is written to a log that outlives the session. gap (low).
• The SGR-Pixels mouse (#819): no new parser. A report in pixels has the same shape as one in cells (CSI < b ; x ; y M), so crossterm's, termion's and termwiz's own SGR parsers read it; the session divides it back into cells by the cell size the kernel's window size gives (never by 0: no size, no pixel mode) and clamps what overflows. The one new answer, DECRQM's for mode 1016, goes through the start-up query's existing reader. A page sees only where it was clicked, inside the box clicked (ClickAt, kept inside the element's border box), which a click at the cell's centre already told it. verified (PTY tests).
• Terminal hosts' APIs (#820): rich_interact::host talks to the terminal's own control channel (terminal-browser's socket, tmux, kitty's or WezTerm's remote control, zellij), which can run commands and type into panes. What holds:
• Commands are words: every adapter runs its program with an argument list, never sh -c; tmux, which hands a pane's command to a shell, gets each word single-quoted (shell_quote, tested against sh with $(…), ; and quotes). verified.
• Only methods the terminal lists in hello are sent; the rest fail before anything is written. verified (a fake socket server).
• Only this user's socket: a path that is not a socket, or is another user's, is refused; a reply is read up to 1 MB with a 5 s timeout, and parsed by serde_json; the reply and its panes have a fuzz target (terminal_host). verified.
• Who calls it: Noctiluca only for --split, which runs its own binary with the user's own command line. send_text is for #816's "send to agent", and must stay a user's action, never driven by page text. to review with #816.
• TERMINAL_BROWSER_TERMINAL_SOCKET and TMUX come from the environment: whoever sets them already runs as the user. accepted.
• --ssh HOST (#817): Chrome and the profile stay on this machine; the SSH server carries every request and resolves every name, as a network would (HTTPS stays end to end; plain HTTP is readable there). Gaps that remain:
• Other local users can use the tunnel while it runs: ssh -D takes SOCKS5 with no authentication, and Chrome cannot speak SOCKS5's password method (nor use a Unix-socket proxy), so a user of this machine who finds the port reaches the remote's network as you. The port is now drawn at random, which makes it harder to find, not impossible. Documented in the guide (on a shared machine, run Noctiluca on the remote instead). The fix is a relay of Noctiluca's own on the port that checks each connection's owner (in /proc/net/tcp on Linux) and forwards over ssh's control socket (-W). gap (medium, shared machines only).
• A kept profile mixes the two localhosts: --profile with and without --ssh shares one site's cookies and storage between this machine's localhost and the remote's. Warned on start and documented. accepted.
• macOS and Windows have no listener-owner check (no /proc/net/tcp), and no death signal for ssh. gap (low).
• Bot checks: the Runtime domain is visible to pages; accepted and documented, not a security gap.

5. rs-rich-embed's PTY host¶

Code: host.rs (PtyHost, LocalPty), term.rs and pane.rs; the emulator is rs-rich-record's (vt100).

Assets: the user's real terminal; the host app's availability; the child's process tree.

Trust boundaries: the child program's output and the host app's screen; the host app and the child (the child runs as the user, unsandboxed: it is the program the app chose to run).

Entry points: every byte the program writes; its exit; resizes and input the app forwards.

Gaps:

• Cell text itself: whether vt100 can store a control or zero-width character in a cell that then reaches the terminal. unverified.
• Queries the emulator answers (device attributes, cursor position): a program learns only what any terminal would tell it. unverified.
• Windows: ConPTY's behaviour, and killing the child's tree there. unverified.

6. TLS, certificates and redirects¶

Code: rs-rich-marketplace's tls.rs, redirect.rs and transport.rs, used by the marketplace, rich URL (the CLI's fetch_url) and the marketplace's download statistics. Chrome does its own TLS.

Assets: the integrity and confidentiality of fetched documents; the user's terminal (for rich URL); the client's availability.

Trust boundaries: the network and the client; the system's certificate store and the bundled roots.

Entry points: server certificates; status lines, headers and Location; bodies, including compressed ones.

Gaps:

• The bundled fallback could override the system's decision. Any TLS or I/O failure with the system's store was retried with the bundled roots, so a root removed from the system store on purpose, or a revocation the platform verifier enforced, could be overridden. The bundled roots are now tried only when the system store cannot be used at all (no CA certificates loaded, or no platform verifier); a certificate the system's verifier refused stays refused (tls.rs, may_be_trust; tested in https_trust.rs). mitigated (0.0.24).
• rich URL followed a redirect from https:// to http:// (as upstream's requests does). It now refuses one before requesting it, with an error naming both addresses; an http:// URL given as such is still fetched (lib.rs, fetch_url; tested in url_fetch.rs; DIVERGENCES §50). mitigated (0.0.24).
• rich URL rendered fetched content unsanitized in upstream's modes, so a server could send escape sequences to the user's terminal (titles, OSC 52 clipboard writes, OSC 8 links). Content fetched from a URL is now sanitized by default in every mode, rich chart and rich profile included; --no-sanitize opts out (same links as above). mitigated (0.0.24).
• No certificate pinning for the official marketplace. Not needed while signatures carry the trust; recorded so the review confirms it.

7. ACP agents for Cornacai¶

Planned. Cornacai is a front end for coding agents over the Agent Client Protocol (JSON-RPC on stdio), built as two new crates, rs-rich-acp and Cornacai (0.0.24 plan, workstream 1). Its design note, docs/design/cornacai.md, is being written in that workstream; this section states the intended model and is reconciled with the design note when it lands.

Assets: the user's workspace and everything outside it; terminals the client starts for the agent; the user's attention and consent (permission prompts); the user's terminal.

Trust boundaries:

• the agent process and Cornacai. ACP does not sandbox the agent: it runs with its own process's permissions, so Cornacai guards only what the agent asks the client to do;
• the agent's text (and anything it read: files, web pages, tool output, any of which may carry prompt injection) and the user's screen;
• the workspace and the rest of the file system.

Entry points: initialize's answer, session/update notifications (text, tool calls, plans, diffs), session/request_permission, fs/read_text_file, fs/write_text_file, terminal/*; the agent's launch command (and, in phase 4, the marketplace's agent kind).

Gaps to settle in the design: whether a terminal the agent starts is confined at all (it runs as the user); an audit log of every approved action; and the session store's location and permissions once sessions are saved.

8. The log console (rich console)¶

Code: console.rs in the CLI, and intuiTUIve's log/console.rs (the tracing plugin, 0.0.24, #815). An app run with INTUITUIVE_CONSOLE sends its tracing events, and the inspector's trace (keys, focus, signal writes), as JSON lines to a Unix domain socket where rich console listens. Unix only for now.

Assets: what the app logs (which may hold the user's data, and the keys typed while the trace is on); the user's terminal, where the console prints.

Trust boundaries: other local users and the socket; the app and the console (the same user); the events' text and the terminal.

Entry points: connections to the socket and the lines they send; the socket's path (--socket, INTUITUIVE_CONSOLE).

Gaps:

• Windows: no named pipe yet; rich console refuses to run and install_console does nothing there. A pipe needs an ACL for the user alone, PIPE_REJECT_REMOTE_CLIENTS, and a check of the server's owner from the client. planned.
• Another user's peer is refused by code that tests cannot reach without a second account; the decision itself is unit-tested. verified (logic), unverified (a live second user).

The review checklist¶

For stage 4. For each item: check the threat against the code at the release candidate and its tests, then fix it, add a test, or record the decision here (with the release that decided it). A finding is reported and handled as SECURITY.md says, not in a public issue.

Plugins¶

• [ ] A ./rich.toml (every table and profile) cannot load a plugin; test each of the UNTRUSTED_* keys.
• [ ] Native plugins: the descriptor checks in read_descriptor, the panic guard in export_dylib_plugin!, and every host that enables dylib-plugins (the Python bindings included).
• [ ] WASM: a module with any import is refused; memory, table, fuel and module-size limits each have a test that hits them; no host function can be reached.
• [ ] WASM: load-time cost of the largest allowed module; whether wasmi's translation is metered.
• [ ] Decide on a per-render or per-process budget for plugin calls.
• [ ] Output sanitizing: every capability kind, with ESC, C1, OSC 8, OSC 52 and bidirectional controls in the fixture.
• [ ] Links and click meta removed from markup and highlighter spans.
• [ ] Name rules and conflicts in add_plugin.

The marketplace and its signer¶

• [ ] Signature checks: wrong key id, revoked key, legacy Ed signatures, a moved signature (serial mismatch), bad trusted comments.
• [ ] Rollback, serial reuse and expiry, per marketplace location.
• [ ] Key rotation: planned, main replaced, backup replaced without main, a revoked key returning, generation order; withholding a generation (the revocation gap).
• [ ] Decide whether marketplace.state.json's cached key chain is re-verified from the root on load, and whether the install directory is made private.
• [ ] Install: size and hash before any write, the path rules, the atomic write, the WASM manifest comparison, every kind's maximum size.
• [ ] Load: every run checks the lockfile; micro packs read after the check.
• [ ] The signing workflow: actions pinned by commit, Python packages pinned by hash, RS_RICH_CLI_REF set to a tag, the environment's required reviewer and branch rule, and the GitHub App's permissions.
• [ ] Listing checks: reserved names, tier and recommendation labels, pull_request only.
• [ ] A warning when the trust root is not the compiled-in one.

rich serve and rs-rich-web¶

• [ ] Token: entropy, constant-time comparison, required by the page and the upgrade; decide whether it moves out of the URL.
• [ ] Origin and Host: cross-site WebSocket hijacking and DNS rebinding, for loopback, specific and unspecified bind addresses, and with --allow-origin.
• [ ] CSP and framing headers on every page; no external loads.
• [ ] Limits: pending connections, request time, sessions, message and frame size, terminal size, output and input backpressure.
• [ ] Session processes: the hello secret, the kill on close and on server death (Unix and Windows), memory and CPU caps; the environment they inherit.
• [ ] xterm.js's OSC handling in program mode (OSC 52 off, OSC 8 links).

Noctiluca and Chrome¶

• [ ] Every string from a page goes through clean before the terminal, including dialog text, download names and bookmarks.
• [ ] Sandbox and DevTools switch filters; decide on an allow-list for other switches.
• [ ] The DevTools pipe on Unix; the Windows port's exposure.
• [ ] Profiles: mode 700, removal on every exit path, kept profiles opt-in.
• [ ] Downloads denied; the quarantine design before it is wired in.
• [ ] Password fields never read.
• [ ] Navigation to file://, chrome:// and javascript: from a page.
• [ ] The control socket (#816), --read-only, and prompt injection through page text, once it lands.
• [ ] --ssh: the host never read as an option, the tunnel on loopback only, the port's owner checked, no direct DNS, WebRTC or QUIC (the live test with Chrome), and the shared-machine gap.
• [x] --ssh: the tunnel's port drawn at random, not in the kernel's order (0.0.24, random_port); the relay that checks each connection's owner is still open.
• [ ] The terminal hosts' API client (#820): commands as words, tmux's quoting, methods only from hello, the socket's owner, and that send_text stays a user's action.
• [x] The terminal hosts' reply parser has a fuzz target (terminal_host: host::parse_reply and host::panes_of; 0.0.24).
• [ ] The pixel mouse (#819): pixel mode only with a known cell size, and RICH_PIXEL_MOUSE=0 turns it off.

The embed PTY host¶

• [ ] No escape sequence from the child reaches the real terminal (a fixture with OSC 0, 8 and 52, DCS and APC strings).
• [ ] Cell text cannot carry control characters.
• [ ] The child's process group is killed on drop; ConPTY on Windows.

TLS and redirects¶

• [ ] Verification is on for every client; no danger configuration.
• [ ] Decide when the bundled-roots fallback applies.
• [ ] HTTPS-only redirects for the marketplace; the hop limits and the overall deadline.
• [ ] Decoded-size limits for every body.
• [ ] Decide on sanitizing rich URL's content by default, and on a downgrade warning.

ACP agents¶

• [ ] Capabilities off by default, and refused before the app when not offered.
• [ ] Workspace confinement: absolute paths, symbolic links, .., races between the check and the use.
• [ ] Writes to hooks and settings ask.
• [ ] Permission prompts show the full command and path, and mark the agent's words.
• [ ] Agent text sanitized; no fetches without the user.
• [ ] Cancellation answers pending requests.
• [ ] The marketplace's agent kind.

The log console¶

• [x] The socket's directory the user's alone, made before the bind and refused (not changed) when others can use it; the socket made 0600 in it right after the bind, the umask untouched (0.0.24, tests in console.rs).
• [x] The peer's user checked on both sides where the platform says (SO_PEERCRED, getpeereid); a symbolic link or a file at the path refused and left alone (0.0.24).
• [ ] A live test with a second user account, on Linux and macOS.
• [ ] The Windows named pipe: its ACL, remote clients refused, the server's owner checked by the app, once it is built.

Across surfaces¶

• [ ] Every parser of outside input has a fuzz target, and the four-week clean run of fuzzing is met.
• [ ] An advisory check (cargo audit or cargo deny) runs in CI against the lockfiles; none does today.
• [ ] The mitigations marked documented or unverified above are read in the code and tested, and their state updated here.