装DSH插件前,五步查清包和权限

关注「山海只能局」，用东方文化看懂现代科技。

这是一篇已复现的静态审计方法，不是 dsh-context 已跑通的证明。我们在 macOS 的 Python 3.12.14 环境里，下载固定 npm 包、对照注册表 SHA-512、读取归档目录与入口代码，得到了可复核的审计报告；没有安装插件、授权账号、重启 DSH Profile 或执行真实会话任务。

DeepSeek Harness（DSH）0.1.7-rc.2 的官方发布记录涉及插件详情和安装错误提示的修复，也调整了自动审阅入口。插件管理界面越方便，越需要在点击安装前看清来源与权限。GitHub 有 dsh-context 仓库，npm 有 0.56.2 包；存在于仓库、出现在搜索结果、包能下载，是三个不同状态。我们选择这个样本，因为它声称提供上下文面板与 /context 命令，且注册表给出可固定的包版本。

本文的验收目标很窄：在不运行第三方代码的条件下，得到一个包含固定版本、完整性匹配、归档文件清单、Bundle 声明、敏感代码路径和未验证事项的本地报告。若这些信息有矛盾，停止安装；若它们一致，只能进入下一轮隔离运行测试。

适用系统是有 curl、jq、tar、OpenSSL 的 macOS 或 Linux；本文本地自动审计脚本用 Python 3.12.14 标准库运行，不调用 DSH。示例输入是 npm 包 dsh-context 的精确版本 0.56.2，不是会随时间变化的 latest。需要公网访问 npm 注册表，但不用 Cookie、API Key 或 DSH 账号。下载的是公开软件包；本次没有付费 API 调用，网络流量约为一个不足 1 MB 的归档加元数据。

开始前新建独立空目录，别把归档下载到生产项目，也别执行 npm install、npm pack 生命周期脚本或仓库 README 的安装命令。下方步骤以这个空目录为工作目录。所有文件名固定，避免把今天检查的元数据和明天更新的包混在一起。

在终端输入：curl -fsSL https://registry.npmjs.org/dsh-context/0.56.2 -o metadata.json。随后输入：jq -r '.name,.version,.dist.tarball,.dist.integrity,.gitHead' metadata.json。预期依次看到 dsh-context、0.56.2、以 dsh-context-0.56.2.tgz 结尾的 tarball 地址、sha512- 开头的完整性字段和一个源码提交号。若返回的版本不是 0.56.2，立即停下；不要把 latest 的结果拿来验证旧包。

本次读到的 npm 包 gitHead 为 198ec93105bc942f2b576133edc01eed25a624d2，而同日仓库最新提交另为 423ea4f2acb7ea14c81776955682129d24e352be。两者不能默认为同一份源码。审计时应保存包元数据、归档和仓库提交三个身份，后续比较时才知道自己实际检查的是哪一个对象。

运行：curl -fsSL https://registry.npmjs.org/dsh-context/-/dsh-context-0.56.2.tgz -o dsh-context-0.56.2.tgz。接着运行：openssl dgst -sha512 -binary dsh-context-0.56.2.tgz | openssl base64 -A。把输出与 metadata.json 中 dist.integrity 去掉 sha512- 前缀后的字符串逐字比较。本次两者相同，说明下载的字节与注册表声明一致。

这一步只验证传输对象的一致性，不证明注册表包无恶意代码，也不证明它和 GitHub 最新提交一致。若摘要不同，不要重试安装；先删除有问题的下载文件，重新获取固定元数据和包，并核对网络缓存或镜像是否换包。若企业网络替换了下载地址，应记录镜像来源并请安全负责人复核。

运行：tar -tzf dsh-context-0.56.2.tgz。预期看到 package/package.json、package/cordis.patch.yml、package/lib/index.js、package/lib/client.js 等路径。本次归档列出 10 个条目，没有绝对路径或 .. 穿越路径，也没有符号链接；这是压缩包结构检查，不是代码安全结论。

再运行：tar -xOf dsh-context-0.56.2.tgz package/cordis.patch.yml。输出的补丁行声明 id 和 name 为 dsh-context。npm 元数据同时声明 host 入口、Web client 注入项及兼容版本。Bundle 声明说明平台打算怎样接入插件，不能证明宿主实际允许这些能力，也不能证明页面显示的兼容状态经一次性 Profile 重启验证。

归档里若出现绝对路径、../、可执行脚本或你无法解释的安装脚本，先停下人工审查。不要为了“看一眼”而在当前用户 Profile 下执行包。我们的检查脚本只用 tarfile 在内存中读文件，没有解压运行第三方 JavaScript。

运行：tar -xOf dsh-context-0.56.2.tgz package/lib/index.js | rg -n 'fetch[(]|readFile|apiKey|authorization|child_process|writeFile'。本次入口代码可见读取本地 manifest、通过 DSH 会话句柄读取日志的路径；还可见以配置的 baseURL 请求 /user/balance，并在 Authorization 头使用 API Key 的代码。它们与“上下文统计”和“余额显示”的功能有关，但仍涉及会话内容与凭证边界，安装前应确认目标域名、授权范围、调用时机和失败处理。

关键词搜索不是完整安全审计：minify、动态加载、依赖包和运行时注入都可能躲过扫描。本次自动报告把网络、凭证、文件读取命中列为人工复核线索，不把命中数写成风险评分；未看到写文件或子进程关键词，也不等于此包在所有环境里无法写文件或执行命令。

确认代码后，做一张权限表：它能读取哪些会话；是否能接触 API Key；是否向配置的服务发网络请求；Web client 注入哪些宿主模块；哪些数据会持久化。若其中一项无法解释，就不要进入真实账户测试。

本次使用随内容包保存的 Python 标准库脚本读取同一个归档与注册表原文，输出 audit_result.json。命令的参数是 --tarball dsh-context-0.56.2.tgz、--registry-json metadata.json、--output audit_result.json；脚本要求 SHA-512 匹配，否则直接退出。报告给出 10 个归档条目、零危险路径、Bundle 与 client 注入声明，并明确标注 static_archive_audit_not_runtime_acceptance。

读者复核报告时至少检查四项：包名与版本是否固定，完整性是否匹配，归档是否有穿越路径，敏感代码命中是否逐条解释。输出能用于“是否值得进入下一轮测试”的决定，不能用于“插件已安全可用”的广告。我们的完整性检查在本机约 0.16 秒完成，下载约 0.57 秒；这是命令返回耗时，不包含人工审查与网页截图时间，也不代表插件运行成本。

如果要升级为运行验收，还须在一次性 DSH Profile 上安装固定包，记录宿主授予的权限，完成一次重启，再用虚构会话验证面板与 /context 的最终输出，随后执行卸载和回滚检查。今天没有做这些动作，reproducible 只指静态审计方法可复现，不指插件功能。

第一类是版本漂移：latest 改版后，元数据与归档不配对。恢复方式是只使用 /0.56.2 的固定地址和同版本 tarball；不要用仓库 HEAD 替代已发布包。第二类是完整性不匹配：停止审查，保留错误记录并重新取原始注册表，不能通过忽略校验继续安装。第三类是权限解释不清：会话日志、API Key 或网络请求若超出你的预期，不把包放进日常 Profile；在隔离环境看清代码与宿主授权再决定。

还要注意第四类失败：关键词扫描没有命中，被误当成零权限。脚本只能识别显式字符串，依赖注入和动态调用需要更深的代码审阅。隐私边界是不要把真实账户密钥、私人聊天、客户项目放进初试样本；费用边界是本流程不需付费 API，但会消耗网络流量和审查时间。安全边界是本流程完全不执行插件。

这五步把“我看见一个插件”变成“我能说清固定包的来源、结构和疑点”。它没把风险消灭，却把安装决定从猜测推进到可复核记录。下一次若拿到隔离运行截图、权限提示、重启日志、真实任务输出和回滚结果，才能把这篇静态审计升级为插件使用实测。