dsh-wsl-workspace

检测报告

能力清单

• 可执行外部程序spawns-processes高关注3 处命中
  • lib/wsl-DN2-D6tr.js:1import { execFile, execFileSync } from "node:child_process";
  • lib/wsl-relay.js:5import { spawn } from "node:child_process";
  • lib/wsl-search.js:6import { execFile } from "node:child_process";
  • 看它调用哪些程序。调用本机已有的工具是常见做法。
• 以 shell 执行命令shell-exec高关注3 处命中
  • lib/index.js:629" shell: true",
  • lib/wsl-DN2-D6tr.js:201const value = execFileSync("reg.exe", [
  • lib/wsl-DN2-D6tr.js:212const name = execFileSync("reg.exe", [
  • 看命令字符串是拼出来的还是写死的。拼接用户输入才是真正的风险。
• 覆盖内置工具tool-shadowing高关注2 处命中
  • glob, grep
  • 看它是否覆盖了 DSH 内置同名工具。覆盖会改变你已有习惯的行为。
• 写入文件writes-files需留意16 处命中
  • lib/fs.js:55await rename(tempPath, destPath);
  • lib/fs.js:65await rename(tempPath, destPath);
  • lib/index.js:1976if (!existsSync(dest) && existsSync(previous)) renameSync(previous, dest);
  • lib/index.js:1977if (existsSync(previous)) rmSync(previous, {
  • 看写入位置。写自己的配置目录是正常的，写系统目录不是。
• 启动伪终端spawns-pty需留意4 处命中
  • CHANGELOG.md:447Measured with the host's own node-pty: same relay, same `\\wsl.localhost\…`
  • CHANGELOG.md:475the relay through a real ConPTY with the host's own node-pty and requires the
  • CHANGELOG.zh.md:163- **DSH Desktop 上持久 shell 又能用了（issue #40）**。Desktop 的宿主进程**本身就是**打包后的 Electron 可执行文件、以 node 模式运行（`ELECTRON_RUN_AS_NODE=1…
  • CHANGELOG.zh.md:167- `scripts/compatibility/conpty-relay.mjs`：**新的常驻门禁**——在真实 ConPTY 下用宿主自己的 node-pty 跑中继，要求解析出的解释器给出活的 bash 提示符。这正是 #40 破坏…
  • 伪终端等于给了一个完整 shell。确认这是插件的核心功能。
• 可终止进程kills-processes需留意1 处命中
  • lib/wsl-jobs.js:143process.kill();
  • 看它终止的是自己启动的进程，还是按名字匹配到的任意进程。
• 发起网络请求network需留意1 处命中
  • lib/client.js:70response = await fetch(ENDPOINT, {
  • 看请求发往哪些域名。发往作者自己的后端是常见做法。
• 读取环境变量reads-env一般22 处命中
  • lib/index.js:227env: process.env,
  • lib/index.js:340const systemRoot = process.env.SystemRoot ?? "C:\\Windows";
  • lib/index.js:343PATH: [join(systemRoot, "System32"), process.env.PATH ?? ""].filter(Boolean).join(";"),
  • lib/index.js:2009return process.env.SystemRoot ?? process.cwd();
  • 环境变量里常混有密钥。看它是否把整个 env 都读走。
• 读取文件reads-files一般21 处命中
  • lib/index.js:1000readdir: async (path, options) => readdir(path, options),
  • lib/index.js:1001readFile: async (path, options) => readFile(path, options),
  • lib/index.js:1040entries = await io.readdir(joinUnc(distro, dir), { withFileTypes: true });
  • lib/index.js:1169dirents = await io.readdir(root.path, { withFileTypes: true });
  • 读文件是绝大多数插件的正常工作方式，本身不构成顾虑。
• 接触凭据或密钥credentials一般1 处命中
  • TESTING.md:201# copy settings.yaml / .credentials.yaml in, so the first-run welcome is skipped
  • 看它读取哪些凭据、发往哪里。用于登录自己的服务是正常的。
• 动态加载模块dynamic-import一般1 处命中
  • lib/index.js:1891* itself as an archive: a bare `import()` walks the filesystem upward, and an
  • lib/index.js:1928const ns = await import(specifier);
  • 动态导入本身无害，但会让依赖关系难以静态审阅。
• 文中出现远程脚本地址remote-url-reference一般1 处命中
  • TESTING.md:179# https://download.deepseek.com/desktop/dsh-latest-windows-x64.exe -> <dir>/
  • 只是文本里出现了远程脚本地址，没有看到加载它的调用。多半是文档或注释；若确实可疑，搜一下这个地址在包里的其他出现位置。

这份报告的口径

扫描读的是包里的源码，全程不执行第三方代码。 本次读了 30 个文件，扫描于 2026-10-16。 命中次数只说明源码里出现过这类调用，不说明行为好坏——一个插件读写文件 500 次和 1 次 都会被记为「读取文件」。这是能力清单，不是信任评分，也不是安全结论： 没扫出来的能力可能只是写法没被规则覆盖。

依赖安全公告

可信度

• 0没有可扣分的项