From 9455a79dc262d1688631307513fae1e627eba32d Mon Sep 17 00:00:00 2001 From: Mikei386 <44135113+Mikei386@users.noreply.github.com> Date: Wed, 26 Aug 2026 10:18:55 +0200 Subject: [PATCH] harden MCPHub deployer credential boundary --- .../hermes/skills/mcphub-deployer/SKILL.md | 57 ++++++++++++++++--- 1 file changed, 49 insertions(+), 8 deletions(-) diff --git a/platform/hermes/skills/mcphub-deployer/SKILL.md b/platform/hermes/skills/mcphub-deployer/SKILL.md index 6bef8fb..13c0ba7 100644 --- a/platform/hermes/skills/mcphub-deployer/SKILL.md +++ b/platform/hermes/skills/mcphub-deployer/SKILL.md @@ -17,15 +17,21 @@ Use these paths directly. Do not search the filesystem for alternatives. - Container: `MCPHub` - UI/base URL: `http://192.168.1.2:8787` - Operational source/build tree: `/mnt/nvme-storage/appdata/MCPHub/build/repo` -- Dockerfile: `platform/mcphub/Dockerfile` below that tree -- Single server and client registry: `config/mcp-registry.json` -- Registry renderer: `platform/mcphub/configure-settings.py` (normally unchanged) -- Unraid template: `config/unraid-templates/my-MCPHub.xml` +- Dockerfile: `/mnt/nvme-storage/appdata/MCPHub/build/repo/platform/mcphub/Dockerfile` +- Single server and client registry: `/mnt/nvme-storage/appdata/MCPHub/build/repo/config/mcp-registry.json` +- Registry renderer: `/mnt/nvme-storage/appdata/MCPHub/build/repo/platform/mcphub/configure-settings.py` (normally unchanged) +- Versioned Unraid-template source: `/mnt/nvme-storage/appdata/MCPHub/build/repo/config/unraid-templates/my-MCPHub.xml` +- Live DockerMan template: `/boot/config/plugins/dockerMan/templates-user/my-MCPHub.xml` - Persistent state: `/mnt/nvme-storage/appdata/MCPHub` - Secrets: `/mnt/nvme-storage/appdata/MCPHub/secrets/.env`, mode `0600` - Client bearer token: `/mnt/nvme-storage/appdata/MCPHub/client-token` - Individual route: `http://192.168.1.2:8787/mcp/` +The versioned template and the live DockerMan template are different files. +Keep their image tag and required mounts aligned. If the versioned template is +missing, copy the live template to that exact versioned path once; do not search +for another template and do not infer a replacement from unrelated containers. + The operational build tree is persistent and covered by the normal Unraid Appdata backup. The checkout below is legacy and MUST NOT be used or inspected for MCPHub work: @@ -47,14 +53,35 @@ restart discovery after a phase has completed. Check only: 1. `MCPHub` container state, image tag, mounts, and network. -2. The four fixed production files listed above. +2. The fixed Dockerfile, registry, renderer, and both template paths above. 3. Existing MCPHub server names to avoid duplication. 4. Target service reachability or the upstream release. 5. Required secret-file presence; never print its values. 6. Current Git availability, if any. -Never run a filesystem-wide `find`. Never read unrelated Compose stacks, -repositories, documentation trees, or all container logs. +Never run `find` to rediscover a listed path. Never read unrelated Compose +stacks, repositories, documentation trees, container logs, container +environments, application configs, home directories, or secret stores. + +### Credential boundary — mandatory stop + +Credentials and account configuration are user-supplied inputs, not discovery +targets. This rule overrides the desire to complete a deployment or live test. + +- Never inspect another container, service, environment, mount, config file, + mailbox, shell history, password manager, or secret directory to obtain or + infer credentials. +- Never reuse credentials found in an existing mail server or another app + unless the user explicitly names that exact source and authorizes reuse. +- Check only whether the dedicated fixed secret file for this server exists; + do not read its values during preflight. +- If the MCP needs credentials or account settings and the dedicated file is + absent or incomplete, finish all credential-independent build work, install + the server disabled, and stop before live authentication. Ask the user for + the missing fields and state the exact secret-file path. +- Do not substitute inspection of an existing service for that question. +- A missing credential may reduce verification to build plus MCP handshake; it + is never permission to investigate the user's infrastructure. ### 2. Classify once @@ -83,6 +110,11 @@ contradicts it. Ask only for information that cannot be derived safely: credentials, a material license decision, or an ambiguous destructive permission. +For mail-related MCPs, repository inspection may determine which field names +are required, but the IMAP/SMTP host, user, password/token, sender identity, and +TLS choices must come from the user or the dedicated secret file. The presence +of a Docker mail server does not answer those questions. + ### 4. Implement the smallest change Modify only the necessary fixed production files. Rules: @@ -96,7 +128,8 @@ Modify only the necessary fixed production files. Rules: - Preserve existing users, bearer keys, prompts, resources, enabled states, and per-tool toggles. - Build a new image tag. Never overwrite the tag currently running. -- Update the Unraid template to the exact new tag. +- Update both the versioned template source and the live DockerMan template to + the exact new tag. Do not rebuild `template.xml` inside an upstream image. For servers exposing many tools, install disabled first. After a successful local test, enable only the required tool groups in MCPHub. Do not publish an @@ -111,6 +144,11 @@ Preserve all Appdata and mounts. Never restart Athena, Router, Qwen, Hermes, OpenWebUI, WireGuard, Unraid, or unrelated containers for an MCPHub deployment. +Do not use unrestricted host shell access during repository analysis, +classification, or credential preflight. Use it only after the exact file +changes, new image tag, verification steps, and rollback tag are known. Its +scope is then limited to those declared paths and the `MCPHub` container. + ### 6. Prove the result Verify, in this order: @@ -123,6 +161,9 @@ Verify, in this order: 6. No test download, queue item, write, or second backend remains. 7. If installed disabled, return it to disabled after the temporary test. +If credentials are unavailable, steps 3 and 5 may be recorded as blocked. +Never weaken the credential boundary merely to make the live probe pass. + A running container alone is not success. Never claim install, test, registration, Git push, or backup without observing its result.