mise Packslip 签名验证与安装策略发布发现、签名者连续性与沙箱化安装机制【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise 通过 Packslip 的签名元数据signed metadata来发现软件发布、验证发布者身份并挑选适配当前平台的构建产物。本文是 mise 中 Packslip 后端校验与策略体系的完整技术指南涵盖发布发现规则、版本解析、签名校验、签名者连续性signer continuity、stamps 审批策略、制品选择与宿主要求等核心机制读者阅读后可掌握 Packslip 后端的安全模型并能独立排查packslip:工具的安装失败、签名变更与策略冲突问题。安装示例与工具选项请先参阅 Packslip 后端文档。核心概念manifest、bundle、artifact 与签名发布列表在进入校验细节之前先明确 Packslip 体系的四个基础对象它们是本文后续所有规则的前提manifest清单描述一次发布release的声明文件由发布者签名。bundle捆绑包由该 manifest 及其签名证据signature evidence组成的整体是 mise 实际下载并验证的对象。artifact制品manifest 中指名的一个可下载构建产物build例如hk-linux-x86_64.tar.xz。signed release list签名发布列表对多个版本进行索引的签名列表可以推荐recommend或撤回withdraw某个版本。mise 安装packslip:工具时只信任签名 manifest后端不会从任意发布文件名推断安装方式。这一点在 src/backend/packslip.rs 的模块注释中有明确表述无论走 GitHub 发布发现还是域名发布列表都是packslip 指明哪个制品适合当前主机、其 digest 与大小、以及其中包含哪些可执行文件因此没有任何信息是靠文件名猜出来的。检查工具与已接受的签名者在调查一个校验错误之前先确定实际使用的后端与版本并在不改变任何状态的前提下检查签名者状态mise tool hk mise ls --current mise packslip pins mise packslip pins --json将上面的hk替换为受影响的工具。注意mise packslip pins别名list列出的是此前已接受的签名者身份它既不会重新验证某个已安装的可执行文件也不会向新签名者授予信任。在遵循签名者轮换流程之前应将相关项目的锁文件mise.lock条目与错误信息进行对照。该命令的实现在 src/cli/packslip/pins.rs--json输出完整的 pins 数据普通模式则渲染为表格展示每个项目的 Scheme签名方案、Signer签名者、Attested byvendor 或 repackager以及 Provenance是否带构建来源链接。若尚无任何 pin命令会输出no packslip signers pinned yet。项目发现Project DiscoveryPackslip 项目的标识形式决定了 mise 去哪里寻找发布信息项目形式mise 查找位置github.com/owner/repoGitHub 发布中携带packslip.sigstore.json的版本。github.com/owner/repo/tools/mytool该仓库的发布使用packslip.tools-mytool.sigstore.json。tool.example.comhttps://tool.example.com/.well-known/packslip.json。example.com/tools/mytoolhttps://example.com/.well-known/packslip/tools/mytool.json。这些规则的源码依据位于 src/backend/packslip.rs 的bundle_name()与well_known_url()函数GitHub 单仓项目使用固定文件名packslip.sigstore.jsonmonorepo 子路径中的/会被替换为-得到packslip.tools-mytool.sigstore.json域名项目则拼出.well-known/packslip.json或.well-known/packslip/path.json。几个必须理解的关键约束monorepo 子路径只定位工具签名身份仍钉在仓库上github.com/owner/repo/tools/mytool表示该仓库发布中的一个工具但签名身份signing identity仍然归属于整个仓库。无论 bundle 的文件名是什么被签名的项目和版本都必须与请求的工具和发布一致。域名项目必须依赖签名发布列表签名列表提供 bundle URL制品artifact可以托管在另一个下载主机上。没有签名发布列表的域名项目无法安装。识别出某 forge 的签名签发者并不等于发现发布GitHub 有内置的 release-API 集成因此可以直接读取发布其他托管主机必须提供签名发布列表的位置否则 mise 无从发现版本。项目名的规范化逻辑同样在 src/backend/packslip.rs 的project_name()中jdx/hk这类不含.的写法会被补全为github.com/jdx/hk而tool.example.com这类含主机名的写法按原样处理mise 会把packslip:tool.example.com解析为对https://tool.example.com/.well-known/packslip.json的请求。版本解析Version ResolutionPackslip 版本遵循语义化版本semantic versioning包括兼容的日期版本例如2026.9.1。版本本身决定了排序与预发布状态GitHub 的发布顺序release order和可编辑的 prerelease 标志都不决定版本的排序或预发布状态预发布版本默认被排除除非启用prerelease工具选项。对于 GitHub 发现mise 从标签tag中读取版本例如v1.2.3、mytool-v1.2.3或v4.1会被规范化为4.1.0。无法映射为版本的标签需要显式出现在签名列表中。安装时manifest 中的版本必须与标签或列表条目一致。签名发布列表Signed Release ListsGitHub 仓库可以在其默认分支上发布一个补充性签名列表位置为单仓项目.well-known/packslip.jsonmonorepo 工具.well-known/packslip/tool.json该列表可以撤回withdraw某个版本提供某个版本的 bundle URL 与 digest补充release API 未暴露的版本。关于未列出的语义需要特别注意GitHub 项目中被省略的版本仍可来自 GitHub 发布省略不等于撤回域名项目中签名列表提供整个发布索引厂商撤回优先于一切即使某个受信任的 stamper 批准了该版本厂商撤回依然会将其排除。发布列表的连续性与最低发布年龄mise 会拒绝以下签名列表已过期的列表序列号sequence低于该项目此前接受过的最高序列的列表。一旦 mise 接受过某个补充性 GitHub 列表该列表的消失会被视为错误。这是为了防止列表缺失被用来悄悄撤销一次撤回。记住的列表状态与 签名者 pin 存放在一起——在源码层面src/packslip_pins.rs 的Pins结构同时维护pins签名者映射和sequences每个项目已接受的最高列表序列号且读写时持有文件锁packslip/pins.lock避免两个并发安装进程互相丢弃对方的 pin 或序列。启用 最低发布年龄minimum_release_age时发现阶段的时间戳会帮助过滤候选版本。默认值为24h即默认只安装发布满 24 小时的版本支持相对时长7d、6mo、1y与绝对日期2024-06-01。在下载制品之前mise 会以经过验证的透明度日志时间戳verified transparency-log timestamp对照生效截止时间只有被明确允许的 unlogged bundle 才会改用签名的发布时间戳。推荐与回退Recommendations and Fallback对于不受约束的latest请求mise 的候选顺序是厂商签名列表中的签名推荐signed recommendation若无签名指针则使用 GitHub 的最新发布latest release若没有符合条件的推荐选择最高符合条件的语义化版本。前缀请求如node20与渠道请求channel保持各自的常规匹配规则推荐不会重排它们。候选必须通过签名、身份、digest、发布年龄、stamping 与宿主检查。策略排除policy exclusion会产生警告并尝试下一个候选但不同类型的失败处理方式截然不同不合格的签名推荐直接回退到语义化版本选择不再咨询 GitHub 的指针签名或 digest 失败、列表无效/过期/回滚/意外缺失停止解析stop resolution而不是跳过继续。对于 stamped 发布mise 从 stamp 的 URL 获取 bundle并检查厂商列表中是否有撤回以及记录的 digest。解析与安装使用相同的来源与相同的验证策略这是保证解析到的版本一定可安装的关键设计。缓存与离线使用在线版本列表与latest解析每次都会重新读取策略因此撤回与信任变更会即时生效结果会写入 mise 的 remote-version 缓存。离线时两者都使用该缓存若缓存为空则返回无版本。安装时仍然会重新检查验证策略。仅有缓存的版本列表不足以完成离线安装所需的 bundle、制品与信任证据trust evidence也必须可用。验证检查Verification Checks在解包一个发布之前mise 会按顺序执行以下检查签名与证书证据bundle 的签名、适用的证书和透明度日志证据必须对得上预期的仓库身份或配置的密钥manifest 结构manifest 的结构、请求的项目与版本以及厂商列表或受信任 stamper 记录的 bundle digest连续性策略签名者连续性signer continuity、锁文件承诺lockfile commitments以及适用的发布年龄策略制品完整性所选制品的 digest 与大小以及已有的锁文件校验和。验证通过后被验证的 manifest 会作为.mise-packslip.json保留在安装目录中见 src/backend/packslip.rs 的STATEMENT_FILE常量为资源resources如补全与 skills提供可执行文件路径与元数据。e2e 测试 e2e/backend/test_packslip 就断言了安装后$install_path/.mise-packslip.json中存在project: packslip.dev字段。需要澄清的边界验证能认证签名者与下载字节但不能证明软件本身安全manifest 中的 provenance构建来源链接是独立证据mise 只记录其存在性以用于连续性检查不会去抓取并验证链接到的构建 provenance。签名者连续性Signer Continuitymise 在两个地方保留信任状态状态记录内容state 目录 下的packslip/pins.toml此前接受的签名者、签名方案、vendor 与 repackager 状态、provenance 链接是否存在以及发布列表连续性。mise.lock项目的签名者与 attestor 承诺连同每个平台制品的 URL 与校验和——包括在另一台机器上首次安装时的承诺。从源码看src/packslip_pins.rs 中每个Pin记录schemesigstore-oidc或sigstore-key、signer、issuer、attested_byvendor或repackager、provenance、unlogged与pinned_at。连续性比较的核心逻辑在check_against()keyless 签名者的连续性按工作流路径比较忽略其 tag 或 branch ref同一工作流的新发布标签视为同一签名者见signer_of()它会把https://...ref中最后一个之后的 ref 去掉而 email、SPIFFE URI 这类本身可能含的身份则不会被误切。新的工作流路径或新密钥需要一次显式的信任决策。以下变化也可能被拒绝签名方案变更、vendor 到 repackager 的降级attested_by从vendor变为repackager、以及丢失 provenance 链接。被拒绝时mise 会给出错误提示并建议如果厂商宣布了变更请运行mise packslip forget project后重新安装下一次被接受的发布将设置 pin。 相应的重置命令为mise packslip forget github.com/jdx/hk关于pins.toml的删除文档给出了明确警告删除pins.toml会重置本机所有已记录项目的连续性它不是安装失败的常规补救手段它不会移除项目锁文件中的签名者承诺。签名变更的检查与重置命令包括显式选项和锁文件承诺如何影响轮换详见 Packslip 后端文档的 pinned-signers 一节。Stamps审批宿主与镜像stamper盖章服务可以是注册表registry、镜像mirror或审查服务review service它发布一份签名列表列出它批准的发布。默认情况下不要求任何 stamp。要启用需要配置你信任的宿主以及每个宿主列表的签名密钥或身份[settings.packslip] stampers [ stamps.example.com/path/to/stamper.pub, reviews.example.comhttps://github.com/example/reviews/, ]每个条目都是hostPIN形式。PIN 可以是一行 minisign 格式的公钥一个公钥文件路径.pub一个 GitHub 身份前缀如https://github.com/org/registry/用于 keyless 签名。请将示例宿主和密钥路径替换为你信任的服务与 pin。该设置的完整定义见 docs/settings.toml环境变量为MISE_PACKSLIP_STAMPERS源码解析逻辑在 src/packslip_stamps.rs 的Stamper::parse()不带的条目、不含.或含/的宿主名都会被拒绝。一个宿主为每个项目发布一份列表位于https://host/.well-known/packslip/project.json。配置 stampers 后生效以下规则一个版本需要至少一个受信任宿主的非 yanked 批准才能被列出或安装一个宿主的撤回不会否决另一个宿主的批准厂商撤回仍然排除该发布与 stamps 无关mise 先检查 stamped bundle digest 与厂商列表 digest如果存在再验证厂商签名——stamp 永远不会替代厂商签名没有 digest 的 stamp 会被拒绝批准必须指明 bundle 的内容而不只是 URL过期、回滚、无效或此前已接受但现在缺失的 stamper 列表都会导致错误。若要让某个工具豁免 stamp 要求、同时保留厂商签名验证可以为该工具设置trust vendor工具选项见 Packslip 后端文档[tools] packslip:github.com/jdx/hk { version latest, trust vendor }镜像Mirrorsstamper 可以镜像完全相同的厂商签名 bundle。mise 会从 stamp 的 URL 获取它并检查厂商列表中的撤回与已记录 digest。要点删除 GitHub 发布资产不会阻止对厂商尚未撤回的发布使用已批准的镜像需要独立身份策略的 repackager 重新签名 bundle在此处不受支持。解读策略失败Interpreting Policy Failures失败类型下一步签名者或签名方案变更将旧 pin 和锁文件承诺与发布者公告的轮换进行对照签名列表过期、回滚或消失检查发布者或 stamper 的当前列表删除本地状态会丢弃连续性检查发布被撤回或缺少必需 stamp选择配置策略允许的发布bundle 或制品 digest 不匹配检查发布来源或镜像不要为了消除错误而接受新字节没有匹配的制品或无法解决并列项检查平台与变体或请发布者在 manifest 中区分其构建宿主要求失败安装该要求或改用受支持的宿主绕过检查并不能满足该要求文档特别强调不同错误标识不同阶段——修改制品选项无法修复无效签名遗忘签名者 pin 也无法修复 digest 不匹配。排查时可用调试输出定位问题MISE_DEBUG1 mise install packslip:github.com/jdx/hk制品选择Artifact Selectionmise 使用签名元数据选择一个制品选择顺序为匹配 OS、架构与 libc缺失的字段只会让该维度不受限——例如一个 universal macOS 构建仍然要求 macOS变体过滤指定了variant时只考虑该变体未指定时只考虑没有变体的制品格式偏好保留 mise 能安装的格式优先选择最具体的平台匹配然后在同一平台内优先于裸可执行文件的归档/压缩格式拒绝未解决的并列在两个构建之间绝不猜测。格式偏好在源码中有明确的优先级数组src/backend/packslip.rs 的FORMAT_PREFERENCEtar.xztar.zsttar.gztgztar.bz2tarzip7zxzzstgzbz2raw。重要限制安装器格式installer formats如deb、dmg、msi不会被选择因为 mise 安装到自己的目录glibc 宿主机在没有匹配的 GNU 制品时可以使用 musl 制品mise 会在 debug 日志中报告这一回退发布者必须用变体来区分替代构建客户端选项无法解决两个描述完全相同的制品。宿主要求Host Requirements选择制品后、下载之前mise 会检查制品声明的宿主要求。要求检查不会打破选择并列也不会改选另一个构建。要求检查结果mise 行为确认缺失库、glibc 不足或 OS 版本不足拒绝安装。缺失或过期的必需命令警告并继续。无法完成的检查警告而不是假定宿主不兼容。命令检查的实现细节优先使用当前激活的 mise 工具而不是环境 PATH 中的命令mise 检查的是 OS 可执行路径在 Windows 上git.exe或node.cmd算数但仅带 shebang 的脚本不算。库检测是平台相关的macOS 上缺失的库文件可能仍存在于 dyld 共享缓存中因此 mise 将该缺失报告为unknownLinux 上OS 版本来自uname -r的内核发布号读到发行版后缀为止6.8.0-31-generic会被比较为6.8.0。如果需要无视已确认的失败继续安装可以使用ignore_requirements工具选项见 Packslip 后端文档。但要牢记它不会提供缺失的库也不会让不兼容的可执行文件运行起来。从源码看完整信任链综合 src/backend/packslip.rs、src/packslip_pins.rs 与 src/packslip_stamps.rs 三个模块可以梳理出 mise 的完整信任链发现GitHub 项目走 release API packslip.sigstore.json资产域名项目走.well-known/packslip.json签名列表解析版本必须是 semverlatest优先厂商签名推荐其次 GitHub 指针最后最高语义化版本验证验证 bundle 签名keyless OIDC 工作流身份或pubkey公钥、manifest 项目与版本、digest 与大小连续性与packslip/pins.toml中的旧 pin 比较拒绝签名者/方案/vendor 身份降级与 provenance 丢失并记录列表序列号防回滚策略应用minimum_release_age时间门槛与 stampers 批准要求选择与安装按 OS/arch/libc/variant/格式选择制品检查宿主要求解包后保留.mise-packslip.json供补全与 skills 使用。这一信任链的设计核心是解析与安装同源同策离线时缓存只影响版本枚举安装时的验证与策略检查从不被绕过。【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
mise Packslip 签名验证与安装策略：发布发现、签名者连续性与沙箱化安装机制
mise Packslip 签名验证与安装策略发布发现、签名者连续性与沙箱化安装机制【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise 通过 Packslip 的签名元数据signed metadata来发现软件发布、验证发布者身份并挑选适配当前平台的构建产物。本文是 mise 中 Packslip 后端校验与策略体系的完整技术指南涵盖发布发现规则、版本解析、签名校验、签名者连续性signer continuity、stamps 审批策略、制品选择与宿主要求等核心机制读者阅读后可掌握 Packslip 后端的安全模型并能独立排查packslip:工具的安装失败、签名变更与策略冲突问题。安装示例与工具选项请先参阅 Packslip 后端文档。核心概念manifest、bundle、artifact 与签名发布列表在进入校验细节之前先明确 Packslip 体系的四个基础对象它们是本文后续所有规则的前提manifest清单描述一次发布release的声明文件由发布者签名。bundle捆绑包由该 manifest 及其签名证据signature evidence组成的整体是 mise 实际下载并验证的对象。artifact制品manifest 中指名的一个可下载构建产物build例如hk-linux-x86_64.tar.xz。signed release list签名发布列表对多个版本进行索引的签名列表可以推荐recommend或撤回withdraw某个版本。mise 安装packslip:工具时只信任签名 manifest后端不会从任意发布文件名推断安装方式。这一点在 src/backend/packslip.rs 的模块注释中有明确表述无论走 GitHub 发布发现还是域名发布列表都是packslip 指明哪个制品适合当前主机、其 digest 与大小、以及其中包含哪些可执行文件因此没有任何信息是靠文件名猜出来的。检查工具与已接受的签名者在调查一个校验错误之前先确定实际使用的后端与版本并在不改变任何状态的前提下检查签名者状态mise tool hk mise ls --current mise packslip pins mise packslip pins --json将上面的hk替换为受影响的工具。注意mise packslip pins别名list列出的是此前已接受的签名者身份它既不会重新验证某个已安装的可执行文件也不会向新签名者授予信任。在遵循签名者轮换流程之前应将相关项目的锁文件mise.lock条目与错误信息进行对照。该命令的实现在 src/cli/packslip/pins.rs--json输出完整的 pins 数据普通模式则渲染为表格展示每个项目的 Scheme签名方案、Signer签名者、Attested byvendor 或 repackager以及 Provenance是否带构建来源链接。若尚无任何 pin命令会输出no packslip signers pinned yet。项目发现Project DiscoveryPackslip 项目的标识形式决定了 mise 去哪里寻找发布信息项目形式mise 查找位置github.com/owner/repoGitHub 发布中携带packslip.sigstore.json的版本。github.com/owner/repo/tools/mytool该仓库的发布使用packslip.tools-mytool.sigstore.json。tool.example.comhttps://tool.example.com/.well-known/packslip.json。example.com/tools/mytoolhttps://example.com/.well-known/packslip/tools/mytool.json。这些规则的源码依据位于 src/backend/packslip.rs 的bundle_name()与well_known_url()函数GitHub 单仓项目使用固定文件名packslip.sigstore.jsonmonorepo 子路径中的/会被替换为-得到packslip.tools-mytool.sigstore.json域名项目则拼出.well-known/packslip.json或.well-known/packslip/path.json。几个必须理解的关键约束monorepo 子路径只定位工具签名身份仍钉在仓库上github.com/owner/repo/tools/mytool表示该仓库发布中的一个工具但签名身份signing identity仍然归属于整个仓库。无论 bundle 的文件名是什么被签名的项目和版本都必须与请求的工具和发布一致。域名项目必须依赖签名发布列表签名列表提供 bundle URL制品artifact可以托管在另一个下载主机上。没有签名发布列表的域名项目无法安装。识别出某 forge 的签名签发者并不等于发现发布GitHub 有内置的 release-API 集成因此可以直接读取发布其他托管主机必须提供签名发布列表的位置否则 mise 无从发现版本。项目名的规范化逻辑同样在 src/backend/packslip.rs 的project_name()中jdx/hk这类不含.的写法会被补全为github.com/jdx/hk而tool.example.com这类含主机名的写法按原样处理mise 会把packslip:tool.example.com解析为对https://tool.example.com/.well-known/packslip.json的请求。版本解析Version ResolutionPackslip 版本遵循语义化版本semantic versioning包括兼容的日期版本例如2026.9.1。版本本身决定了排序与预发布状态GitHub 的发布顺序release order和可编辑的 prerelease 标志都不决定版本的排序或预发布状态预发布版本默认被排除除非启用prerelease工具选项。对于 GitHub 发现mise 从标签tag中读取版本例如v1.2.3、mytool-v1.2.3或v4.1会被规范化为4.1.0。无法映射为版本的标签需要显式出现在签名列表中。安装时manifest 中的版本必须与标签或列表条目一致。签名发布列表Signed Release ListsGitHub 仓库可以在其默认分支上发布一个补充性签名列表位置为单仓项目.well-known/packslip.jsonmonorepo 工具.well-known/packslip/tool.json该列表可以撤回withdraw某个版本提供某个版本的 bundle URL 与 digest补充release API 未暴露的版本。关于未列出的语义需要特别注意GitHub 项目中被省略的版本仍可来自 GitHub 发布省略不等于撤回域名项目中签名列表提供整个发布索引厂商撤回优先于一切即使某个受信任的 stamper 批准了该版本厂商撤回依然会将其排除。发布列表的连续性与最低发布年龄mise 会拒绝以下签名列表已过期的列表序列号sequence低于该项目此前接受过的最高序列的列表。一旦 mise 接受过某个补充性 GitHub 列表该列表的消失会被视为错误。这是为了防止列表缺失被用来悄悄撤销一次撤回。记住的列表状态与 签名者 pin 存放在一起——在源码层面src/packslip_pins.rs 的Pins结构同时维护pins签名者映射和sequences每个项目已接受的最高列表序列号且读写时持有文件锁packslip/pins.lock避免两个并发安装进程互相丢弃对方的 pin 或序列。启用 最低发布年龄minimum_release_age时发现阶段的时间戳会帮助过滤候选版本。默认值为24h即默认只安装发布满 24 小时的版本支持相对时长7d、6mo、1y与绝对日期2024-06-01。在下载制品之前mise 会以经过验证的透明度日志时间戳verified transparency-log timestamp对照生效截止时间只有被明确允许的 unlogged bundle 才会改用签名的发布时间戳。推荐与回退Recommendations and Fallback对于不受约束的latest请求mise 的候选顺序是厂商签名列表中的签名推荐signed recommendation若无签名指针则使用 GitHub 的最新发布latest release若没有符合条件的推荐选择最高符合条件的语义化版本。前缀请求如node20与渠道请求channel保持各自的常规匹配规则推荐不会重排它们。候选必须通过签名、身份、digest、发布年龄、stamping 与宿主检查。策略排除policy exclusion会产生警告并尝试下一个候选但不同类型的失败处理方式截然不同不合格的签名推荐直接回退到语义化版本选择不再咨询 GitHub 的指针签名或 digest 失败、列表无效/过期/回滚/意外缺失停止解析stop resolution而不是跳过继续。对于 stamped 发布mise 从 stamp 的 URL 获取 bundle并检查厂商列表中是否有撤回以及记录的 digest。解析与安装使用相同的来源与相同的验证策略这是保证解析到的版本一定可安装的关键设计。缓存与离线使用在线版本列表与latest解析每次都会重新读取策略因此撤回与信任变更会即时生效结果会写入 mise 的 remote-version 缓存。离线时两者都使用该缓存若缓存为空则返回无版本。安装时仍然会重新检查验证策略。仅有缓存的版本列表不足以完成离线安装所需的 bundle、制品与信任证据trust evidence也必须可用。验证检查Verification Checks在解包一个发布之前mise 会按顺序执行以下检查签名与证书证据bundle 的签名、适用的证书和透明度日志证据必须对得上预期的仓库身份或配置的密钥manifest 结构manifest 的结构、请求的项目与版本以及厂商列表或受信任 stamper 记录的 bundle digest连续性策略签名者连续性signer continuity、锁文件承诺lockfile commitments以及适用的发布年龄策略制品完整性所选制品的 digest 与大小以及已有的锁文件校验和。验证通过后被验证的 manifest 会作为.mise-packslip.json保留在安装目录中见 src/backend/packslip.rs 的STATEMENT_FILE常量为资源resources如补全与 skills提供可执行文件路径与元数据。e2e 测试 e2e/backend/test_packslip 就断言了安装后$install_path/.mise-packslip.json中存在project: packslip.dev字段。需要澄清的边界验证能认证签名者与下载字节但不能证明软件本身安全manifest 中的 provenance构建来源链接是独立证据mise 只记录其存在性以用于连续性检查不会去抓取并验证链接到的构建 provenance。签名者连续性Signer Continuitymise 在两个地方保留信任状态状态记录内容state 目录 下的packslip/pins.toml此前接受的签名者、签名方案、vendor 与 repackager 状态、provenance 链接是否存在以及发布列表连续性。mise.lock项目的签名者与 attestor 承诺连同每个平台制品的 URL 与校验和——包括在另一台机器上首次安装时的承诺。从源码看src/packslip_pins.rs 中每个Pin记录schemesigstore-oidc或sigstore-key、signer、issuer、attested_byvendor或repackager、provenance、unlogged与pinned_at。连续性比较的核心逻辑在check_against()keyless 签名者的连续性按工作流路径比较忽略其 tag 或 branch ref同一工作流的新发布标签视为同一签名者见signer_of()它会把https://...ref中最后一个之后的 ref 去掉而 email、SPIFFE URI 这类本身可能含的身份则不会被误切。新的工作流路径或新密钥需要一次显式的信任决策。以下变化也可能被拒绝签名方案变更、vendor 到 repackager 的降级attested_by从vendor变为repackager、以及丢失 provenance 链接。被拒绝时mise 会给出错误提示并建议如果厂商宣布了变更请运行mise packslip forget project后重新安装下一次被接受的发布将设置 pin。 相应的重置命令为mise packslip forget github.com/jdx/hk关于pins.toml的删除文档给出了明确警告删除pins.toml会重置本机所有已记录项目的连续性它不是安装失败的常规补救手段它不会移除项目锁文件中的签名者承诺。签名变更的检查与重置命令包括显式选项和锁文件承诺如何影响轮换详见 Packslip 后端文档的 pinned-signers 一节。Stamps审批宿主与镜像stamper盖章服务可以是注册表registry、镜像mirror或审查服务review service它发布一份签名列表列出它批准的发布。默认情况下不要求任何 stamp。要启用需要配置你信任的宿主以及每个宿主列表的签名密钥或身份[settings.packslip] stampers [ stamps.example.com/path/to/stamper.pub, reviews.example.comhttps://github.com/example/reviews/, ]每个条目都是hostPIN形式。PIN 可以是一行 minisign 格式的公钥一个公钥文件路径.pub一个 GitHub 身份前缀如https://github.com/org/registry/用于 keyless 签名。请将示例宿主和密钥路径替换为你信任的服务与 pin。该设置的完整定义见 docs/settings.toml环境变量为MISE_PACKSLIP_STAMPERS源码解析逻辑在 src/packslip_stamps.rs 的Stamper::parse()不带的条目、不含.或含/的宿主名都会被拒绝。一个宿主为每个项目发布一份列表位于https://host/.well-known/packslip/project.json。配置 stampers 后生效以下规则一个版本需要至少一个受信任宿主的非 yanked 批准才能被列出或安装一个宿主的撤回不会否决另一个宿主的批准厂商撤回仍然排除该发布与 stamps 无关mise 先检查 stamped bundle digest 与厂商列表 digest如果存在再验证厂商签名——stamp 永远不会替代厂商签名没有 digest 的 stamp 会被拒绝批准必须指明 bundle 的内容而不只是 URL过期、回滚、无效或此前已接受但现在缺失的 stamper 列表都会导致错误。若要让某个工具豁免 stamp 要求、同时保留厂商签名验证可以为该工具设置trust vendor工具选项见 Packslip 后端文档[tools] packslip:github.com/jdx/hk { version latest, trust vendor }镜像Mirrorsstamper 可以镜像完全相同的厂商签名 bundle。mise 会从 stamp 的 URL 获取它并检查厂商列表中的撤回与已记录 digest。要点删除 GitHub 发布资产不会阻止对厂商尚未撤回的发布使用已批准的镜像需要独立身份策略的 repackager 重新签名 bundle在此处不受支持。解读策略失败Interpreting Policy Failures失败类型下一步签名者或签名方案变更将旧 pin 和锁文件承诺与发布者公告的轮换进行对照签名列表过期、回滚或消失检查发布者或 stamper 的当前列表删除本地状态会丢弃连续性检查发布被撤回或缺少必需 stamp选择配置策略允许的发布bundle 或制品 digest 不匹配检查发布来源或镜像不要为了消除错误而接受新字节没有匹配的制品或无法解决并列项检查平台与变体或请发布者在 manifest 中区分其构建宿主要求失败安装该要求或改用受支持的宿主绕过检查并不能满足该要求文档特别强调不同错误标识不同阶段——修改制品选项无法修复无效签名遗忘签名者 pin 也无法修复 digest 不匹配。排查时可用调试输出定位问题MISE_DEBUG1 mise install packslip:github.com/jdx/hk制品选择Artifact Selectionmise 使用签名元数据选择一个制品选择顺序为匹配 OS、架构与 libc缺失的字段只会让该维度不受限——例如一个 universal macOS 构建仍然要求 macOS变体过滤指定了variant时只考虑该变体未指定时只考虑没有变体的制品格式偏好保留 mise 能安装的格式优先选择最具体的平台匹配然后在同一平台内优先于裸可执行文件的归档/压缩格式拒绝未解决的并列在两个构建之间绝不猜测。格式偏好在源码中有明确的优先级数组src/backend/packslip.rs 的FORMAT_PREFERENCEtar.xztar.zsttar.gztgztar.bz2tarzip7zxzzstgzbz2raw。重要限制安装器格式installer formats如deb、dmg、msi不会被选择因为 mise 安装到自己的目录glibc 宿主机在没有匹配的 GNU 制品时可以使用 musl 制品mise 会在 debug 日志中报告这一回退发布者必须用变体来区分替代构建客户端选项无法解决两个描述完全相同的制品。宿主要求Host Requirements选择制品后、下载之前mise 会检查制品声明的宿主要求。要求检查不会打破选择并列也不会改选另一个构建。要求检查结果mise 行为确认缺失库、glibc 不足或 OS 版本不足拒绝安装。缺失或过期的必需命令警告并继续。无法完成的检查警告而不是假定宿主不兼容。命令检查的实现细节优先使用当前激活的 mise 工具而不是环境 PATH 中的命令mise 检查的是 OS 可执行路径在 Windows 上git.exe或node.cmd算数但仅带 shebang 的脚本不算。库检测是平台相关的macOS 上缺失的库文件可能仍存在于 dyld 共享缓存中因此 mise 将该缺失报告为unknownLinux 上OS 版本来自uname -r的内核发布号读到发行版后缀为止6.8.0-31-generic会被比较为6.8.0。如果需要无视已确认的失败继续安装可以使用ignore_requirements工具选项见 Packslip 后端文档。但要牢记它不会提供缺失的库也不会让不兼容的可执行文件运行起来。从源码看完整信任链综合 src/backend/packslip.rs、src/packslip_pins.rs 与 src/packslip_stamps.rs 三个模块可以梳理出 mise 的完整信任链发现GitHub 项目走 release API packslip.sigstore.json资产域名项目走.well-known/packslip.json签名列表解析版本必须是 semverlatest优先厂商签名推荐其次 GitHub 指针最后最高语义化版本验证验证 bundle 签名keyless OIDC 工作流身份或pubkey公钥、manifest 项目与版本、digest 与大小连续性与packslip/pins.toml中的旧 pin 比较拒绝签名者/方案/vendor 身份降级与 provenance 丢失并记录列表序列号防回滚策略应用minimum_release_age时间门槛与 stampers 批准要求选择与安装按 OS/arch/libc/variant/格式选择制品检查宿主要求解包后保留.mise-packslip.json供补全与 skills 使用。这一信任链的设计核心是解析与安装同源同策离线时缓存只影响版本枚举安装时的验证与策略检查从不被绕过。【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考