whitemagic-mcp 10.4.0 → 10.5.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/README.md +2 -2
  2. package/SECURITY.md +109 -0
  3. package/package.json +3 -2
package/README.md CHANGED
@@ -41,14 +41,14 @@ Or try the binary directly:
41
41
 
42
42
  ```bash
43
43
  npx -y whitemagic-mcp@next selftest # invariant self-test + host diagnostics
44
- npx -y whitemagic-mcp@next --version # wm 10.4.0
44
+ npx -y whitemagic-mcp@next --version # wm 10.5.1
45
45
  npx -y whitemagic-mcp@next doctor # environment health check
46
46
  ```
47
47
 
48
48
  The binary is cached under `~/.cache/whitemagic/bin/<release-tag>/`
49
49
  (respects `XDG_CACHE_HOME`). `@next` tracks the v10 line; unpinned
50
50
  `@latest` installs fetch the stable v9 line instead. Pin the exact
51
- release with `whitemagic-mcp@10.4.0`, or override the release
51
+ release with `whitemagic-mcp@10.5.1`, or override the release
52
52
  tag with `WHITEMAGIC_RELEASE`.
53
53
 
54
54
  ## Try it without installing (hosted read-only lane)
package/SECURITY.md ADDED
@@ -0,0 +1,109 @@
1
+ # Security Policy
2
+
3
+ > NOTE (2026-09-14; platform note updated 2026-10-01 for the macOS x86_64 +
4
+ > Windows x86_64 gates): the support-window policy is decided. Supported
5
+ > releases are the current minor and the previous minor on the install-gated
6
+ > lines (Linux x86-64, Linux arm64, macOS arm64 + x86_64, Windows x86_64).
7
+ > Older minors are archival.
8
+
9
+ ## Supported Versions
10
+
11
+ | Release line | Support |
12
+ | ------------ | ------- |
13
+ | Current minor (latest release) | Security and bug fixes |
14
+ | Previous minor | Security fixes |
15
+ | Older minors | Archival — no fixes |
16
+
17
+ ## Reporting a Vulnerability
18
+
19
+ We take the security of WhiteMagic seriously. If you have discovered a
20
+ security vulnerability, please report it privately.
21
+
22
+ **Do NOT file a public issue.**
23
+
24
+ Instead, please report vulnerabilities by:
25
+
26
+ 1. Opening a GitHub Security Advisory (preferred)
27
+ 2. Emailing security@whitemagic.dev
28
+
29
+ Please include:
30
+
31
+ - Description of the vulnerability
32
+ - Steps to reproduce
33
+ - Affected versions
34
+ - Potential impact
35
+ - Suggested fix (if any)
36
+
37
+ We will acknowledge receipt within 48 hours and provide a detailed response
38
+ within 7 days.
39
+
40
+ ## Security Model
41
+
42
+ WhiteMagic v9 is a trusted local single-user process. Its security model:
43
+
44
+ - **Local-first by default**: all data stays in the local LMDB store; no
45
+ telemetry is sent anywhere by default — the only off-device paths are the
46
+ explicit opt-ins (install funnel, product telemetry) and the optional
47
+ read-only hosted evaluation lane.
48
+ - **Curated tool surface**: the release profile exposes the memory/session
49
+ workflow; the tool archive surface is opt-in (registered total 237 at the
50
+ v5.8.0 release gate, 2026-08-20 — a dated figure, not today's exposure;
51
+ current-build exposure is profile-selected per the Q03 generated manifest,
52
+ with per-tool dispositions under Q04 audit).
53
+ - **Destructive confirmation**: 12 destructive tools require an explicit
54
+ `route=` match plus `confirm: true` and are structurally unreachable via
55
+ natural-language routing.
56
+ - **Read-only mode**: `--readonly` refuses every tool that declares writes and
57
+ suppresses karma, friction, and mutable-state persistence.
58
+ - **Fail-closed compartments**: unknown compartment values get no read or
59
+ write access.
60
+ - **Privacy flags**: `is_private` memories never appear in MCP read/search/
61
+ list/query responses; `model_exclude` memories never enter model context or
62
+ reasoning evidence.
63
+ - **Exact transactions**: `transaction.begin/rollback` snapshot and restore
64
+ byte-equivalent records; rollback failures stay retryable.
65
+ - **Karma chain**: SHA-256 hash chain over dispatch records, with optional
66
+ external Merkle anchors for tamper evidence. Pre-linkage (legacy) entries
67
+ are counted and disclosed per store by `wm doctor` as `N legacy
68
+ (linkage-only)` — they sit outside deep verification and must not be read
69
+ as chain-verified.
70
+ - **Input validation**: request budgets, rate limiting, parameter caps,
71
+ injection filtering, SSRF protection, and path-traversal protection at the
72
+ MCP boundary.
73
+
74
+ Important: `_meta.user_id` from an MCP client is not an authenticated
75
+ identity. Do not deploy the MCP server as a multi-tenant authorization
76
+ boundary.
77
+
78
+ ## Host Identity and Delegation Stance (2026-09-10)
79
+
80
+ Context: Glama MCP-security series (MCP Dev Summit Mumbai 2026) —
81
+ host-as-identity-blind-spot (2026-07-25), confused-deputy HR demo
82
+ (2026-07-02), execution sandboxing (2026-06-30). Tracked as
83
+ `rsi:proposal:active` P-OBO-1 / P-DEPUTY-2.
84
+
85
+ - **Single-user local process.** WhiteMagic has no OAuth / OBO token
86
+ issuance or validation, no SPIFFE workload identity, and no per-user
87
+ scoping. The mesh node key (`WM_MESH_KEY` Ed25519, signed heartbeats)
88
+ names a *device/node*, never a user. See
89
+ `docs/S9_SECURITY_BRIEF_2026-09-10.md` for mesh-identity gaps and the
90
+ pending key-separation ruling.
91
+ - **Server enforces, callers assert.** Human approval (`confirm: true`)
92
+ is not authorization: every destructive dispatch is re-checked
93
+ server-side (Dharma/Yama gates, firebreak veto + bulk-scope law,
94
+ compartment checks). Routing scope (gateway top-level `scope=`) and
95
+ tool-payload scope (inner `args.scope`, e.g. `code.claim` lease scope)
96
+ are separate namespaces — inner scope never re-routes (Q03 regression
97
+ `pinned_proxy_preserves_inner_args_scope`).
98
+ - **Audit carries both ends where known.** Write-audit journal entries
99
+ record the dispatch actor from server-side context plus optional
100
+ OBO-shaped delegation fields (`actor_act`, `actor_on_behalf_of`,
101
+ `delegation_chain` — opaque, server-asserted, absent by default).
102
+ Client-supplied identity claims are never trusted for authorization.
103
+ - **Four-A's self-check** (per deployment, answer honestly):
104
+ Administer — can you name/suspend/deprovision every node holding
105
+ credentials? Authenticate — short-lived node keys with rotation, or
106
+ standing keys? Authorize — least-privilege profiles per store,
107
+ destructive surface enumerated? Audit — can you replay who did what,
108
+ through which agent, last Tuesday, from the karma chain + journal
109
+ alone? Any "not really" is a known gap, not a silent assumption.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "whitemagic-mcp",
3
- "version": "10.4.0",
3
+ "version": "10.5.1",
4
4
  "description": "Local-first sovereign cognitive kernel and memory for AI coding agents over MCP - pure Rust, zero-telemetry, Landlock LSM sandbox.",
5
5
  "license": "MIT",
6
6
  "bin": {
@@ -9,7 +9,8 @@
9
9
  "files": [
10
10
  "bin/",
11
11
  "README.md",
12
- "LICENSE"
12
+ "LICENSE",
13
+ "SECURITY.md"
13
14
  ],
14
15
  "engines": {
15
16
  "node": ">=18"