whitemagic-mcp 10.5.0 → 10.6.0
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.
- package/README.md +2 -2
- package/SECURITY.md +109 -0
- 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.
|
|
44
|
+
npx -y whitemagic-mcp@next --version # wm 10.6.0
|
|
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.
|
|
51
|
+
release with `whitemagic-mcp@10.6.0`, 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.
|
|
3
|
+
"version": "10.6.0",
|
|
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"
|