MemPalace 安全策略详解：版本支持边界、私有漏洞报告通道与仓库中的供应链防护实践

本文基于仓库根目录的 SECURITY.md 展开，完整梳理 MemPalace 的版本支持政策与漏洞报告流程（仅通过 GitHub 私有漏洞报告 Private Vulnerability Reporting 接收，不接受公开 Issue），并结合 CHANGELOG.md 中的安全修复记录、docs/RELEASING.md 的发布流程与 docs/HISTORY.md 的仿冒域名事件，说明这套安全策略在实际仓库中如何落地。读完后，你将知道：哪些版本仍在安全修复范围内、发现漏洞后如何提交一份合格的报告、以及该项目在 hook 注入、路径穿越、凭据管理等方面做过的具体加固。

版本支持政策：安全修复只落在当前主版本线

SECURITY.md 明确了 MemPalace 遵循语义化版本（Semantic Versioning），安全修复只落在当前主版本线上。其版本支持矩阵为：

版本	是否支持
3.x（当前）	是
2.x 及更早	否

这一"当前主版本线"指向的具体版本号可以从仓库中直接核实。版本号的单一事实来源是 mempalace/version.py，当前值为 3.8.0；pyproject.toml 中的包版本同样为 3.8.0。docs/RELEASING.md 还说明版本号需要在六处保持同步（mempalace/version.py、pyproject.toml、两个插件清单等），并有 version-guard.yml 工作流和 tests/test_version_consistency.py 之类的测试来钉住一致性。

对使用者的实际含义是：如果你运行的是 2.x 或更早版本，即使发现了影响你的安全漏洞，官方也不会为该版本线提供修复，升级到 3.x 是当前策略下唯一的获取安全补丁途径。CHANGELOG.md 开头也声明项目遵循 Keep a Changelog 格式并遵守 Semantic Versioning，与该政策一致。

漏洞报告通道：仅接受私有报告，禁止公开 Issue

SECURITY.md 的开篇就给出了明确红线：请勿通过公开 GitHub Issues 报告安全漏洞。报告路径是 GitHub Private Vulnerability Reporting（GHPVR），具体操作分三步：

1. 打开本仓库的 Security 选项卡；
2. 点击 Advisories → Report a vulnerability；
3. 在下表单中填入下述报告要素。

选择私道的动机在文档中体现为"We take the security of MemPalace seriously"——公开 Issue 会立即暴露可利用细节给攻击者，私有报告则允许维护方在补丁发布前控制信息扩散窗口。

报告中应包含的内容

SECURITY.md 要求报告者提供以下四项要素：

• 描述性摘要：对漏洞本身的说明；
• 详细复现步骤：包括任何 proof-of-concept 脚本或具体文件路径；
• 受影响的版本与平台；
• 潜在影响与严重性评估。

结合仓库实际结构，报告者可以给出的具体路径示例包括：hook 脚本位于 hooks/ 目录（如 hooks/mempal_save_hook.sh）、MCP 服务入口在 mempalace/mcp_server.py、存储后端实现在 mempalace/backends/ 下。附带这些真实路径的 PoC 会显著降低分诊成本。

报告之后可以期待什么

SECURITY.md 承诺了三个明确的时间与流程节点：

• 目标在 48 小时内确认收到报告；
• 会对问题进行分诊（triage），并在通往补丁的进展中持续向报告者同步状态；
• 漏洞修复且更新发布后，会发布一份 安全公告（security advisory），并在报告者愿意的情况下署名致谢。

这套"确认—分诊—公告—致谢"闭环与 PyPI 生态常用的 GHPVR 流程一致，也解释了为什么 CHANGELOG 中会记录安全公告发布（见下节）。

从 CHANGELOG 看安全策略的落地：真实的安全修复记录

安全策略不是孤立文件。CHANGELOG.md 中多次出现独立的 Security 小节，可以印证该项目确实在持续执行漏洞修复与加固，且部分修复正是报告/审计流程的产物：

3.3.x 周期（2026-04 中旬）

• "Security hook injection fix (#812)"——修复 hook 注入问题；
• "Restrict file permissions on sensitive palace data (#814)"——收紧敏感 palace 数据文件的权限；
• "entity_registry.research() defaults to local-only (#811)"——此前会未经用户显式同意发起出站 Wikipedia HTTPS 请求，改为默认本地，需显式传 allow_network=True 才联网；
• "Tightened SECURITY.md with a real version-support policy and the GHPVR-only reporting channel (#810)"——即本文所讲的版本支持矩阵与私有报告通道的收紧本身，也有对应的变更记录。

3.2.0（2026-04-12）

• "Harden palace deletion, WAL redaction, and MCP search input handling (#739)"——加固删除操作、WAL 脱敏与 MCP 搜索输入处理；
• "Consistent input validation, argument whitelisting, concurrency safety (#647)"——统一输入校验与参数白名单；
• "Remove hardcoded credential paths from benchmark runners (#177)"——移除基准测试脚本中的硬编码凭据路径；
• "Remove global SSL verification bypass in convomem_bench (#176)"——移除全局 SSL 校验绕过。

3.1.0（2026-04-09）

• "Harden inputs, fix shell injection (#387)"、"Shell injection fix in hooks, Claude Code mining (#114)"——针对 hook 与挖掘链路的 shell 注入修复；
• "Sanitize SESSION_ID in save hook to prevent path traversal (#141)"——对 save hook 的 SESSION_ID 做净化，防止路径穿越；
• "Sanitize error responses and remove sys.exit from library code (#139)"——净化错误响应，避免错误信息泄露内部细节；
• "Mark MD5 as non-security in miner drawer ID generation (#53)"——明确 miner 抽屉 ID 生成中的 MD5 仅作非安全用途（避免误读其强度）。

从 CHANGELOG 的记录看，安全修复集中在三类攻击面：shell/hook 注入、输入与路径净化、以及凭据与网络出口治理。这也提示报告者：若你关注的风险点属于这三类，CHANGELOG 可作为"该问题是否已被修复"的快速检索入口。

供应链与仿冒域名防线：安全策略的延伸

MemPalace 的"安全"范畴在仓库文档中不止于代码漏洞。README.md 开头以醒目提示警告仿冒网站，docs/HISTORY.md 记录了 2026-04-11 的"仿冒域名与恶意软件"事件（社区在多个 issue 中报告了伪造 MemPalace 网站分发恶意软件的情况）。文档明确项目仅有的官方入口为：

• 本 GitHub 仓库（MemPalace/mempalace）；
• PyPI 包 mempalace；
• 官方文档站 mempalaceofficial.com。

其他任何域名（包括 .tech、.net 或其他 .com 变体）均被视为仿冒。对使用者的实际建议是：只从 PyPI 安装、只信任上述入口，遇到其他域名的"MemPalace 官网"按仿冒处理。

发布侧的供应链防护在 docs/RELEASING.md 中有完整说明，可视为安全策略在发布管线的落地：

• PyPI 可信发布（Trusted Publishing / OIDC）：上传使用 GitHub 在上传时铸造的短期身份，仓库中不存储任何 API token；
• 人工审批门：publish.yml 工作流在 pypi environment 上暂停等待评审人手动批准后才执行上传；
• 只从 main 发布：工作流会拒绝任何 tag 对应提交不是 main 祖先的发布，且 tag 必须与 mempalace/version.py 一致；
• 入口点对齐检查：发布前要求核验 mempalace-mcp 控制台脚本声明与插件配置一致，防止 pip install 后插件配置指向不存在的可执行文件（历史上 v3.3.2 曾因此出错）。

这些机制共同降低了"供应链投毒"和"仿冒分发包"两条路径的风险，与 SECURITY.md 的私有报告通道形成互补：前者防住外部伪造，后者处理内部漏洞。

给报告者的检查清单

综合 SECURITY.md 与仓库实践，提交漏洞报告前可以按以下清单准备：

1. 先查版本：确认自己运行的版本（mempalace/version.py 对应值，当前为 3.8.0）落在受支持的 3.x 线上；
2. 先查 CHANGELOG：确认该问题是否已在某个版本的 Security 小节中被修复，避免重复报告；
3. 走私有通道：通过仓库 Security 选项卡的 GHPVR 表单提交，绝不发公开 Issue；
4. 报告要素齐备：摘要、可复现步骤（含真实文件路径或 PoC 脚本）、受影响版本与平台、影响与严重性评估；
5. 等待 48 小时确认：之后关注分诊进展，修复发布后将收到安全公告；
6. 认准官方入口：仅在官方仓库、PyPI 与官方文档站获取软件，警惕仿冒域名。

小结

SECURITY.md 的内容简短但每条都可执行：安全修复只覆盖 3.x 当前主版本线（2.x 及更早已停止），漏洞必须走 GitHub 私有报告通道，报告需含摘要、复现步骤、影响版本平台与严重性四项，处理侧承诺 48 小时内确认、持续分诊同步、修复后发布公告并署名致谢。而 CHANGELOG.md、docs/RELEASING.md 与 docs/HISTORY.md 中的记录表明，这套策略并非纸面文章——hook 注入、路径穿越、shell 注入修复、文件权限收紧、SSL 绕过与硬编码凭据移除、PyPI 可信发布与仿冒域名警示，共同构成 MemPalace 在 v3.8.0 阶段的安全现状。