从哈希锁到 Apple 公证Try Omarchy 供应链信任模型与安全设计全景【免费下载链接】try-omarchyRun Omarchy on MacOS without any setup.项目地址: https://gitcode.com/gh_mirrors/tr/try-omarchyTry Omarchy 让你在 Apple Silicon 的 Mac 上零配置运行 Omarchy Linux 桌面一个签名过的 macOS 应用里装好了 ARM64 Arch Linux 镜像、QEMU 运行时和 Swift 启动器。但零配置不等于不透明——它的供应链安全建立在一套完整的信任链上从哈希锁定的构建输入到逐文件校验的补丁再到 Apple Developer ID 签名与公证。这篇文章用通俗的方式拆解这套设计帮你在享受开箱即用的同时理解它凭什么值得信任。为什么要关心一个 VM 应用的供应链普通用户装个 App 就完了但 Try Omarchy 比较特殊它打包了三层可执行内容——macOS 启动器、QEMU 虚拟机运行时、以及整个 Linux 客制系统。任何一层被篡改风险都不止是应用坏了而是你的剪贴板、摄像头、共享文件夹甚至 Touch ID 签名流程都可能暴露在不可信的代码面前。因此项目的信任模型只回答一个问题每一个进入系统的文件是谁、以什么方式、在哪个哈希之下产生的架构与信任边界的完整描述见 docs/architecture.md。第一道锁钉死上游一个 commit 都不许漂整条供应链的地基是构建规格文件 guest/spec.json。它做的第一件事是把上游 Omarchy 钉死上游 commit精确到c668141e…这个提交而不是最新版tree 哈希treeSha256记录整棵源码树的 SHA-256提交号相同但树被改动也会被拒绝版本与渠道锁定 release4.0.4、channelquattro连许可证都写明。同一份 spec 里还钉着所有第三方组件Hyprland 源码与构建产物的双份 SHA-256、Vivaldi 官方 RPM 及其签名密钥指纹、Ghostty 源码与签名摘要、yay、mise、ttfx……每一个下载都有sha256字段。构建脚本会实际比对摘要不符就整条流水线失败。系统包层面guest/packages.txt 声明需要的 Arch Linux ARM 软件包guest/scripts/resolve-package-lock.py 在空根上解析出完整依赖闭包并写入 guest/packages.lock.json——构建时校验的就是这把锁而不是安装当天的仓库状态。这意味着同一个 spec任何人、任何时候构建装进来的包都一模一样。第二道锁临时补丁逐个哈希前后对照Try Omarchy 会对上游 Omarchy 打一些临时补丁Touch ID 菜单、1Password ARM64 安装器等补丁放在 guest/patches/omarchy/。这里的设计比大多数项目更严格每个 backport 在 spec 中不只记录补丁本身的patchSha256还记录它目标文件修改前和修改后的 SHA-256{ id: touch-id-sudo-menu, patchSha256: 9a415cd0…, targets: [ { path: config/omarchy/extensions/omarchy-menu.jsonc, beforeSha256: 1ca0fdf7…, afterSha256: 39b4fb16… } ] }翻译成人话补丁必须打在一个已知内容的文件上打完之后文件必须长成已知样子。上游一旦更新导致文件变了补丁直接应用失败——它不会尽力而为地改到别的地方。 这也是为什么 Hyprland 是唯一的例外它被可复现地重新构建、打上带哈希守卫的补丁并锁进客制机的本地不可变仓库而不是悄悄混进普通更新。第三道锁出处清单区分原样复制和改过构建完成后guest/scripts/write-provenance.py 生成一份确定性的内容摘要清单。它把客制机内的 Omarchy 运行时树分成两类类别含义例子verbatim原样与钉住的上游逐字节一致applications、default、migrationsbackported已回移应用了枚举补丁每个补丁有输入/输出哈希bin、config、install、shell清单里写着一句核心声明Desktop runtime derived from pinned Basecamp Omarchy source plus the enumerated reviewed backports.桌面运行时源自钉住的上游源码加上已枚举、已审阅的回移补丁。任何没在这份清单里出现的改动都无法进入出厂镜像。两条独立更新通道防止静默升级信任模型里最容易被忽视的一点Mac 应用更新和客制机系统更新是刻意分开的。你换成新版 App不会把新出厂镜像的内容静默灌进现有虚拟机客制机里的内置更新器可以推进普通软件包但直接引导的内核、try-omarchy-runtime和已审阅的兼容性回移补丁仍锁在项目的本地仓库里想要完整的新出厂镜像唯一的途径是用户明确确认的Factory Reset。发布流程docs/releasing.md还要求发布说明里不得宣称内置更新器能复现全部出厂变更——把不会发生的事也写进规则这是很罕见的严谨。最后一公里Developer ID 签名 Apple 公证构建输入全部可信之后交付物本身还要过 Apple 的安检门。打包流程Makefile 的package/release目标是前置检查要求干净的检出、HEAD 上打有精确的vX.Y.Z标签并强制Developer ID Application签名身份与 notarytool 配置文件——两者缺一直接报错Developer ID 签名应用和 DMG 都签名提交公证DMG 送交 Apple 公证服务staple 公证票据把验证票据钉进包内离线也能被 macOS 校验没有公证就拒绝出货两个目标都不会回退到未公证版本。发布清单还要求在发布说明中公布最终 DMG 的 SHA-256 摘要并逐项审计第三方声明THIRD_PARTY_NOTICES.md、许可证材料和 QEMU 的 corresponding-source 义务。换句话说你下载到的每个字节都能回溯到一次被签过、公证过、且摘要公开的构建。明确的信任边界与漏洞报告通道项目并不假装全部代码都是第一方。出厂镜像构建完成之后才运行的可选安装器如 1Password 官方签名发布、Vivaldi 官方 RPM被明确划为独立的信任边界每一个都必须在 spec 中声明交付方式固定签名 RPM、可变厂商发布等由安装器对厂商签名身份做验证且只写入用户自己的客制磁盘不随应用再分发。调用它们本身就是用户跨过这条边界的主动决定。安全方面SECURITY.md 定义了私有漏洞报告流程疑似漏洞请走私有渠道而非公开 issue需附复现步骤、受影响版本和预期影响公开声明的安全敏感区域包括下载的构建输入、产物与清单校验、代码签名、VM 磁盘处理、QEMU 进程边界和客制机到主机的音频桥。快速核对清单如何确认你装的是正版检查点在哪里看下载的是签名并公证的 DMGdocs/releasing.md 的发布流程上游源码钉在哪个 commitguest/spec.json 的upstream字段每个补丁改了什么、前后是什么样子spec 的authenticity.backports哪些树原样、哪些改过guest/scripts/write-provenance.py 生成的出处清单包锁是否覆盖完整依赖闭包guest/packages.lock.json漏洞如何报告SECURITY.md总结Try Omarchy 的信任模型可以浓缩成一句话构建输入用哈希钉死改动用前后摘要逐一锁定出处用确定性清单自证交付物用 Apple 公证背书更新通道彼此隔离。对用户而言这意味着零配置背后不是一句营销口号而是一条可以从 guest/spec.json 一路核对到 DMG 摘要的可验证链条。对开发者而言它也是一份教科书级的供应链安全范例——把信任从感觉变成了可以逐字节检查的事实。【免费下载链接】try-omarchyRun Omarchy on MacOS without any setup.项目地址: https://gitcode.com/gh_mirrors/tr/try-omarchy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考