必须显式设置docker_content_trust=1，否则签名检查完全不生效；它是客户端校验开关，未启用时docker pull静默接受任何镜像，启用后拉取未签名镜像将报错remote trust data does not exist。
必须显式设置 DOCKER_CONTENT_TRUST=1，否则所有签名检查都完全不生效——它不是默认开启的，也不是 Docker 安装后自动启用的。
为什么 DOCKER_CONTENT_TRUST=1 是强制验证的前提
这个环境变量是 Docker 客户端的全局开关：它不控制“是否签名”，而控制“是否校验签名”。未设置时，docker pull 会静默接受任何镜像（无论有没有签名），docker build --push 也不会触发自动签名流程。设置了之后，拉取未签名镜像会直接失败，错误类似：Error: remote trust data does not exist for docker.io/xxx/yyy。
常见误操作包括：
- 只在 CI 脚本里临时 export，但本地 shell 没配，导致开发阶段完全没感知到签名缺失
- 写入
~/.bashrc后没执行source ~/.bashrc，或用的是 zsh 却改了 bashrc - 在 Docker Desktop GUI 中启动终端，它可能不加载 shell 配置文件，需手动 export
docker pull 失败时怎么确认是 Content Trust 导致的
当 DOCKER_CONTENT_TRUST=1 开启后，docker pull 报错通常有两类典型输出：
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
-
remote trust data does not exist：目标 tag 根本没被任何人签过名（最常见） -
signature verification failed：签名存在但校验失败，原因可能是本地时间偏差 >5 分钟、中间代理篡改响应、或 registry 返回的 signature payload 不完整
注意：docker run 本身不直接受该变量控制——它依赖的是镜像拉取时是否已通过签名校验。也就是说，如果镜像是在 DOCKER_CONTENT_TRUST=0 环境下拉下来的，即使之后开了 trust，docker run 仍能运行；反之，若拉取时已校验失败，则根本不会存到本地镜像列表里。
私有 Registry（如 Harbor）必须额外支持签名验证
Docker Hub 默认支持 DCT，但私有仓库不是开个服务就行。Harbor 必须满足两个条件：
- 在 Harbor UI 或配置文件中启用
content_trust功能（对应 backend 是 Notary v2 或 Cosign OCI Artifact 模式） - 确保其 Notary/Cosign 服务可达且证书可信（自签名证书需提前导入系统信任库，否则会报 TLS handshake 错误）
验证方式很简单：在开启 DOCKER_CONTENT_TRUST=1 后执行 docker pull your-harbor.example.com/project/app:v1.0。如果返回 notary.docker.io does not have trust data，说明客户端仍在查 Docker Hub 的 Notary 服务，而非你的 Harbor 实例——这是典型的 registry 地址未正确识别或 Harbor 未启用内容信任的信号。
真正容易被忽略的点在于：签名绑定的是 manifest digest，不是 tag 名字。所以哪怕你给 myapp:latest 签了名，只要后续 docker push 覆盖了这个 tag（指向新 digest），旧签名就立刻失效，下次拉取仍会报 remote trust data does not exist。生产环境必须用语义化版本号（如 v1.2.0）并禁止覆盖已发布 tag。
