机器人嵌入式强化学习人工智能智能硬件计算机视觉音视频【免费下载链接】microduckA Tiny biped duck robot 项目地址https://gitcode.com/gh_mirrors/mi/microduck点击查看免费下载microduckA Tiny biped duck robot 的 OTA 更新系统使用 minisign 签名来确认每一个安装包的真实来源。deploy/dev-key/team.dev.pub就是这个信任体系中的一个特殊成员——它是 CI 给分支构建branch build签名所用的公钥也是让robotctl update apply --ref branch能在开发者板上工作的关键前提。本文围绕这份密钥文件讲解它为什么被刻意放在deploy/trusted_keys/之外、allow_dev_keys与密钥存放位置构成的双重门控如何起效以及在私钥丢失时如何安全地重新签发。team.dev.pub 是什么分支构建的签名公钥在 microduck 的更新架构中updaterd只安装签名验证通过的包。信任的锚点是机器人磁盘上的一个 minisign 公钥集合——trusted_keys_dir生产配置为/etc/robot/trusted_keys见 deploy/updater.toml只要签名能对集合中任意一把公钥验证通过该包就被接受。team.dev.pub是这个集合之外的特殊公钥其职责在 deploy/dev-key/README.md 中说得非常直白team.dev.pub— the public half of the key CI signs branch builds with, sorobotctl update apply --ref branchworks on a board that trusts it.也就是说CI 用与它配对的私钥给某个 git 分支的最新构建签名对应 tag 形如daemon-dev-branch开发者在自己那块信任该公钥的板上执行robotctl update apply --ref my-branchupdater 解析出对应的 dev tag、验证签名通过后安装。这个流程的底层实现在 updater/src/source/github.rsref_tag_for()把传入的分支名原样拼到ref_tag_prefix默认daemon-dev-后面manifest_at_ref()再去拉取该 tag 下签过名的 manifest。相关测试断言了--ref my-branch解析为daemon-dev-my-branch、--ref feature/foo解析为daemon-dev-feature/foo分支名中的斜杠不需要任何改写。ref_tag_prefix默认值定义在 updater/src/config.rsdefault_ref_tag_prefix返回daemon-dev-并在 updater/updater.example.toml 中有详细注释。关键设计是dev tag 与 release tag必须永远不可混淆——dev tag 会随分支最新构建而移动release tag 则不可变latest解析绝不能把 dev tag 当作候选版本。为什么刻意不放进 trusted_keys/信任的是全团队构建物deploy/trusted_keys/目录存放三把发布公钥release-1.pub、release-2.pub、release-3.pubdeploy/trusted_keys/README.md 说明scripts/install.sh会把该目录整体复制到每一台机器人的/etc/robot/trusted_keys/。问题就在这里team.dev.pub一旦被放进trusted_keys/就等于每一台出厂的客户机器人都会信任它而“信任 dev key”的语义是——团队里任何人构建的任何东西这台机器人都会安装。这显然不是客户机器人应有的行为。所以该文件被刻意放在deploy/dev-key/那里“没有任何东西会默认安装它”原文where nothing installs it by default。只有两条路径会把公钥真正送到某块板上scripts/provision-board.sh在给开发者板做 provisioning 时默认发送这份公钥用--no-dev-key可以明确拒绝安装--dev-key PATH则可以从别处指定公钥文件。从 scripts/provision-board.sh 的源码看DEV_KEY_DEFAULT$(dirname $0)/../deploy/dev-key/team.dev.pub是脚本内置的默认值注释明确写着这是为了“新开发者不需要向任何人索要文件就能 provisioning 一块开发板”--no-dev-key会把DEV_KEY置空--dev-key PATH则覆盖默认路径用于“带外移交的密钥”。双重门控密钥在哪 allow_dev_keys 是否为 trueREADME 强调一块板最终是否接受 dev 构建取决于两个互相独立的条件同时成立公钥已存在于该板的trusted_keys_dir/etc/robot/trusted_keys/该板本地updater.toml中的allow_dev_keys true。在客户机器人的生产配置 deploy/updater.toml 中allow_dev_keys false且注释解释了原因would let anything a teammate builds install itself。而 updater/src/config.rs 的测试断言了出厂配置必须为 false——“一台客户机器人绝不能信任 dev key否则它会安装队友构建的任何东西”。注意一个细节这两项都只对本地生效不会被更新覆盖——因为更新流程不碰/etc。开发者板可以本地覆盖这些配置而一次正常升级不会把allow_dev_keys改回去。源码级实现.dev.pub 后缀与 dev_only 标记在 updater/src/verify.rs 中dev key 门控不是靠文件路径特判而是靠文件名后缀约定/// Keys whose filename ends with this are usable only when allow_dev_keys is /// set, so a production robot wont install a team members local build. const DEV_KEY_SUFFIX: str .dev.pub;KeyRing::load()读取trusted_keys_dir下所有*.pub文件凡是以.dev.pub结尾的都被标记为dev_only: true而usable()迭代器只对allow_dev_keys || !dev_only的密钥放行fn usable(self) - impl IteratorItem TrustedKey { self.keys .iter() .filter(move |k| self.allow_dev_keys || !k.dev_only) }也就是说即使某块板误把team.dev.pub放进了trusted_keys_dir只要allow_dev_keys false这把密钥在verify_bytes/verify_file时根本不会被尝试。配套的单元测试dev_key_is_gated直接验证了这个门控——dev 签名的包在生产配置下必须被拒绝只有显式允许时才被接受assert!(ring(pk, true, false).verify_bytes(data, sig).is_err(), dev key must not be usable in production); assert!(ring(pk, true, true).verify_bytes(data, sig).is_ok(), dev key must work when explicitly allowed);另外值得注意的安全细节updaterd链接的是minisign-verify零依赖、只验证不能签名而不是完整的minisigncrate——更新进程“没有理由具备签名能力所以也不应该链接能签名的代码”。签名的能力被隔离在发布侧的 xtask/src/main.rs它作为 publisher 工具从不随机器人发布。提交公钥是安全的私钥只在 ~/.duck-keysREADME 专门回答了“把公钥提交进仓库会不会泄露什么”的疑虑Committing a public key gives nothing away.Signing a build needs the private half, which lives in~/.duck-keysand never leaves it.minisign 的公钥本来就是必须公开才能让任何人验证签名的东西。真正敏感的是私钥它位于开发者机器的~/.duck-keys/不会进入仓库。这和 deploy/trusted_keys/README.md 中对发布密钥的描述一致私钥放在~/.duck-keys和密码管理器中CI 里只有release-1的私钥。这份文件从仓库中“缺席”反而是一种历史教训它过去被完全排除在版本库之外但那并没有保护到双重门控之外任何额外的东西反而让每个新开发者都要为索要一份文件多跑一趟原文cost every new developer a round trip asking someone for a file。私钥丢失时的轮换minisign -R 与手动安装的代价签名体系无法抵御“私钥丢失”只能做轮换。README 给出了重新签发公钥的命令minisign -R -s ~/.duck-keys/team.dev.key -p team.dev.pubminisign -R用私钥文件重新导出对应的公钥并写入team.dev.pub。但这里有一个关键的非对称性README 警告得很明确一块板只信任已经躺在它trusted_keys_dir里的公钥。所以新公钥生成后所有现存开发板都必须手工把新的team.dev.pub安装进各自的trusted_keys_dir否则它们会继续用旧公钥验证、从而拒绝新签名的构建。同样的非对称性也体现在 deploy/trusted_keys/README.md 对发布密钥的说明中一把新 key 只会被“在其之后镜像的机器人”信任轮换只能保护未来、救不了已经在产线上的旧机器人——这正是为什么release-2、release-3要从第一版镜像就开始随机器出厂Shipping the spares now is free; retrofitting them is impossible。生成与校验xtask keygen 与 keycheck如果需要生成新的开发密钥或签发新公钥发布侧工具提供了完整的密钥管理命令xtask/src/main.rscargo xtask keygen --kind dev --name team.dev --out ~/.duck-keys生成开发密钥按设计是不加密的CI 需要非交互签名私钥由密钥存储保护cargo xtask keygen --kind release --name release-4 --out ~/.duck-keys生成发布密钥强制要求加密--password或MINISIGN_PASSWORD因为其威胁模型与生命周期都不同于 dev keycargo xtask keycheck对私钥/公钥做一次签名-验证往返测试确认密钥对匹配。keygen还刻意拒绝把私钥写进仓库——“提交签名私钥是这里唯一无法靠删除文件来弥补的错误”Refusing to write a secret key inside the repository. Committing a signing key is the one mistake here that cannot be undone by deleting the file。实操速览把一块板变成能装分支构建的开发板综合以上机制一块能接受--ref branch构建的开发板需要满足公钥就位通过./scripts/provision-board.sh userhost默认行为发送team.dev.pub或用--dev-key PATH指定不要用--no-dev-key那是给“只接受发布”的板准备的配置放行在该板本地的/etc/robot/updater.toml中设置allow_dev_keys true生产文件默认是false且不会被更新覆盖分支构建存在CI 已为该分支打出daemon-dev-branch的 dev tag 并签名先给 CI 一两分钟完成构建发起安装robotctl update apply --ref my-branchupdater 会把 ref 解析为 dev tag、用信任集验证签名后安装。而客户机器人则天然处于安全状态trusted_keys_dir里没有 dev keyinstall.sh只复制deploy/trusted_keys/allow_dev_keys也是false——两个条件都不满足即使team.dev.pub存在于仓库中也不会改变任何东西。小结deploy/dev-key/team.dev.pub是 microduck 信任模型中“开发与生产边界”的浓缩体现一份提交在仓库中的公钥文件本身毫无秘密可言但它与allow_dev_keys标志、.dev.pub文件后缀约定、provision 流程共同构成了一道只在开发者板上生效的窄门。理解这把密钥的存放位置与双重门控就理解了 microduck 如何在“让团队成员便捷地在真实硬件上安装分支构建”与“客户机器人绝不接受非发布构建”之间取得平衡。赞分享机器人嵌入式强化学习人工智能智能硬件计算机视觉音视频【免费下载链接】microduckA Tiny biped duck robot 项目地址https://gitcode.com/gh_mirrors/mi/microduck点击查看免费下载相关推荐microduck 开发推送指南一条命令在板卡上构建、签名并安装机器人固件dev-push.sh 全解析microduck 开发推送指南一条命令在板卡上构建、签名并安装机器人固件dev push.sh 全解析 导读 scripts/dev push.sh 是机器人嵌入式强化学习人工智能智能硬件计算机视觉音视频NautilusTrader 性能基准测试工程实践Criterion、iai 与 CodSpeed 的测量策略、编写规范与 CI 集成NautilusTrader 性能基准测试工程实践Criterion、iai 与 CodSpeed 的测量策略、编写规范与 CI 集成 NautilusTra机器人嵌入式强化学习人工智能智能硬件计算机视觉音视频Microduck开发板入门从一块空白板到能接收分支构建的AI鸭子机器人Microduck开发板入门从一块空白板到能接收分支构建的AI鸭子机器人 Microduck 开发板dev board是把一块空白 Radxa Zero机器人嵌入式强化学习人工智能智能硬件计算机视觉音视频上一篇从卡顿到丝滑Harbor Redis缓存优化实战指南下一篇2025新范式如何用Code Llama构建智能代码助手的对话模式全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考