go程序调用notary cli校验镜像签名需通过exec.command执行notary命令，确保notary二进制在path中、提前pull信任数据、显式指定角色与证书参数，并用完整digest拉取镜像。
Go 程序如何调用 Notary CLI 校验镜像签名
Notary 官方不提供 Go 原生 SDK，实际集成时基本靠 shell 调用 notary 命令完成校验。直接 exec.Command 调用是最可行的路径，别指望找 github.com/theupdateframework/notary 里的内部包封装出安全、稳定的 API —— 那些包未导出、无文档、接口随时变。
常见错误现象：notary: command not found 或 rpc error: code = Unknown desc = no trust data for ...，前者是环境没装 Notary CLI，后者常因没提前拉取信任数据（notary -s https://notary-server example.com/myapp pull）。
- 必须确保
notary二进制在$PATH中，推荐用go install github.com/theupdateframework/notary/cmd/notary@latest安装 - 校验前先执行
notary -s <server><repo> pull</repo></server>，否则verify必然失败 —— Notary 不会自动同步信任元数据 - 注意
notary verify默认只检查targets/releases角色，若你用的是自定义角色（如targets/staging），得显式加--tlscacert和--roles参数 - Go 中捕获输出时，务必同时读
cmd.Stdout和cmd.Stderr，Notary 把部分关键错误（如证书过期）写在 stdout，而成功日志反而在 stderr
使用 docker/distribution 的 client 拉取镜像时如何嵌入签名校验
原生 docker/distribution 库不感知 Notary，它只管 registry HTTP 协议层。想在校验签名后再拉镜像，不能“在拉取过程中校验”，只能“先校验，再拉取”——这是设计约束，不是实现疏漏。
典型场景：CI 流水线中，构建前强制校验镜像签名有效性，防止运行被篡改的镜像。
立即学习“go语言免费学习笔记（深入）”；
- 校验和拉取必须拆成两个独立步骤：先用
notary verify确认签名有效，再用docker/distribution的client.Pull下载 layer - 注意镜像 digest 一致性：Notary 校验的是 manifest digest（如
sha256:abc...），而docker/distribution拉取时若用 tag（如latest），可能因 registry 覆盖导致 digest 变更；务必用完整 digest 拉取，例如registry.example.com/app@sha256:abc... - Notary server 地址与 registry 地址通常不同（如 registry 是
registry.example.com，Notary 是notary.example.com），需分开配置，别硬编码成同一域名
Go 服务启动时自动校验本地镜像签名的坑
有人想让 Go 编写的运维工具（比如一个镜像扫描器）启动时自动校验本机已有的镜像签名。这不可行 —— Notary 不校验本地存储的镜像，它只校验 registry 上的 manifest 及其关联的 TUF 元数据。本地 docker images 输出的镜像 ID（如 sha256:def...）和 Notary 签名的 manifest digest（sha256:abc...）根本不是一回事。
容易踩的坑：notary verify localhost:5000/myapp:1.0 在本地 registry 未启用 TLS 或未配置正确 CA 时静默失败；或误以为校验成功就等于镜像内容未被篡改 —— 实际上 Notary 只保证 manifest 未被篡改，不验证 layer blob 完整性（那是 registry 自身的 digest 保障范畴）。
- Notary 校验对象永远是 registry 上的 manifest URL，不是本地
/var/lib/docker/下的文件 - 若 registry 是 HTTP（非 HTTPS），Notary 默认拒绝连接，必须加
--tlscacert /dev/null（仅测试）或正确配置私有 CA - 不要混淆
notary list（列出可验证的 tag）和docker inspect结果 —— 前者来自 Notary server 的 targets.json，后者来自本地镜像元数据，二者无直接映射关系
Notary v1 与 Docker Content Trust（DCT）的兼容性问题
Go 程序若要兼容旧版 Docker 引擎（docker.io 对应的官方 Notary server（https://notary.docker.io）。你的私有 registry 若用自建 Notary，DCT 环境变量（DOCKER_CONTENT_TRUST=1）不会自动生效。
真实痛点：你在 Go 里调用 notary CLI 时指定了 -s https://my-notary.example.com，但用户同时设置了 DOCKER_CONTENT_TRUST=1，结果 Notary CLI 仍去连 notary.docker.io —— 因为 notary 优先读 NOTARY_SERVER 环境变量，而非 DCT 相关变量。
- 显式设置
NOTARY_SERVER=https://my-notary.example.com，比命令行-s更可靠（尤其在 exec.Command 中易被忽略） -
DOCKER_CONTENT_TRUST_SERVER是 Docker CLI 用的，notaryCLI 完全不识别它，别混用 - Notary v1 已归档，TUF spec 本身还在演进，但社区重心已转向 Cosign + Sigstore；如果你的新项目刚起步，真没必要深绑 Notary —— Go 生态对 Sigstore 的支持（如
cosign verify+sigstore/cosignGo lib）更活跃、更轻量
Notary 的核心复杂点不在 Go 怎么调，而在它的 TUF 角色模型、密钥生命周期、server 配置三者耦合太紧；一个参数配错，错误信息就只报 failed to validate timestamp role，实际可能是 root.json 过期、快照版本不匹配、或本地时间没同步。这些和 Go 关系不大，但排查时最容易让人以为是代码问题。
