企业官网建设流程全解析

mise paranoid 模式怎么启用才能把文件信任绑定到内容并复验 provenance？

【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise

如果你担心两点——项目里的mise.toml在信任后被人悄悄改动、安装时 mise 直接复用 lockfile 里记录的 provenance 而不重新校验——那么需要启用 paranoid 模式。根据 docs/paranoid.md，paranoid 模式做三件事：禁用自动信任和 CI 信任、把直接文件信任与配置内容绑定（按内容哈希）、在支持的后端上安装时复验 provenance。它不会在批准命令后对该命令做沙箱限制，沙箱属于 docs/sandboxing.md 的范畴。

启用 paranoid 模式

paranoid 是全局设置，项目无法为自身启用或关闭它：

# 全局持久启用 mise settings set paranoid true # 只对单次调用启用 MISE_PARANOID=1 mise install

恢复普通模式：

mise settings set paranoid false

也可以在mise.toml里写[settings]paranoid = true，但按 docs/dev-tools/mise-lock.md 的说法，该设置的完整形态是全局级行为，mise settings set是最直接的启用方式。

文件信任如何绑定到内容

先了解两个模式下的差别，见 docs/cli/trust.md：

• 普通模式下，mise run、mise install、mise exec、mise watch等执行类命令会自动信任其活动配置；只含min_version、纯版本字符串[tools]、无模板[tasks]的"安全配置"甚至不需要信任。信任还会在 git worktree 间共享。
• paranoid 模式下，所有非全局配置文件（包括普通模式不需要信任的格式）都要求显式信任，执行命令的自动信任和 CI 信任豁免全部失效，worktree 间也不再共享信任。

因此启用后，第一次在新项目里运行命令前，先查看配置再信任：

# 查看当前目录及父目录中配置文件的信任状态，不会修改任何信任 mise trust --show # 信任你审阅过的那个文件（把路径换成实际审阅的配置） mise trust path/to/mise.toml

关键机制是：直接文件信任会对文件内容做哈希，文件一旦被编辑就需要重新信任。这正是 paranoid 模式相对普通模式的收益——普通模式下信任一次路径即可，而 paranoid 模式下内容变化会立刻使信任失效。

以下路径是例外，不受内容哈希检查约束（docs/paranoid.md）：

• 全局trusted_config_paths设置允许的路径及其后代；
• 被信任 monorepo 根目录覆盖的后代路径；
• 全局与系统配置——它们由操作者所有，豁免也保证了你可以全局启用 paranoid 本身。

如果两者同时启用，safe 模式优先级更高，它会抑制项目执行与环境注入，配置可以不经过信任提示直接加载；但 safe 模式下成功加载不等于获得了供后续普通或 paranoid 调用使用的信任。

安装时如何复验 provenance

先看 lockfile 的默认行为（docs/dev-tools/mise-lock.md、docs/security.md）：

1. mise lock解析配置中的工具版本请求并写入mise.lock。支持的后端会记录产物 URL、校验和，以及经过验证的 provenance（如 SLSA、Cosign、Minisign、GitHub attestations），新 provenance 在写入前会对每个目标平台的产物做密码学验证。
2. mise install时，如果目标平台的 lockfile 条目同时含有校验和与已验证 provenance，默认会复用记录的 provenance，跳过重复检查和 API 调用。这意味着 lockfile 是信任输入——应从可信来源获取并审阅它；仅有 provenance 字段不构成字节已验证的证明。

启用 paranoid 模式后，第 2 步的复用行为被覆盖：支持且已启用的 provenance 方式（SLSA、Cosign、Minisign、GitHub attestations）在安装时重新运行，而不是因为 provenance 条目存在就跳过。这可能需要网络访问。

注意它的边界，避免预期过高：

• 它不会添加该后端本身不支持的验证方式；
• 不会对 mise 跳过的已安装工具重新扫描。

如果你只想开启 provenance 复验而不进入完整的 paranoid 模式，可以独立启用同一行为（docs/dev-tools/mise-lock.md）：

# mise.toml [settings] locked_verify_provenance = true

或只对单次安装启用：

MISE_LOCKED_VERIFY_PROVENANCE=1 mise install

paranoid = true会自动包含这一行为。

社区插件在 paranoid 模式下的变化

paranoid 模式会拒绝用短名安装不受信任的社区插件，除非自动确认已启用（--yes或MISE_YES=1）、mise 正在 CI 中运行、或安装使用--force。短名插件被视为受信任的条件是：其解析出的 URL 匹配 mise 内置注册表中的 asdf 或 vfox 远端，或该插件维护在mise-pluginsGitHub 组织下。

要安装其他社区插件，在命令行或[plugins]配置中直接给出完整 Git 仓库 URL——显式提供 URL 会绕过注册表信任检查，因为选择来源本身就是你的决定：

mise plugin install example https://github.com/example/asdf-example

普通模式下，mise 对未受信短名插件可能只是警告并询问确认。

验证与常见边界

• 用mise trust --show确认某个配置当前是否处于受信任状态，它只读、不修改任何信任。
• 如果之前对信任提示选了"否"，该文件会被加入 ignore 列表（docs/faq.md）。先mise trust --show查看，再对审阅过的文件运行mise trust path/to/mise.toml重新信任。
• 符号链接配置（如 GNU Stow 场景）可能被跟踪到链接目标路径，此时用mise trust指向实际文件路径。
• 在检测到的 CI 环境中，mise 默认认为配置受信任；只有 paranoid 模式启用后，CI 才会要求显式信任。
• 复验 provenance 依赖网络且只覆盖安装动作：它不创建从未发布过 provenance 的发布的 provenance，也不会对已安装、被跳过的工具重新下载校验。

完成上述配置后的可核对结果是：修改任何已信任的项目配置内容后再运行命令会触发重新信任要求（而不是静默沿用旧信任）；mise install对带 lockfile provenance 的产物会重新执行后端支持的验证路径，而不是直接复用 lockfile 记录。要退出该模式，运行mise settings set paranoid false。

【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise