skopeo standalone-sign 实战指南不上传镜像在本地为镜像清单生成 OpenPGP 签名【免费下载链接】skopeoWork with remote images registries - retrieving information, images, signing content项目地址: https://gitcode.com/GitHub_Trending/sk/skopeo导读skopeo standalone-sign是 skopeo 提供的一个纯本地调试签名工具它只要求你提供一个镜像 manifest 文件、一个 docker 引用和一个 GPG 密钥指纹就能在不上传、不拉取镜像的情况下生成一份符合 containers-signature 规范的签名文件随后可用skopeo standalone-verify在本地完成校验。阅读本文后你将掌握该命令的完整语法、每个参数与选项的精确语义、底层签名调用链源码级并理解它与skopeo copy --sign-by的定位差异能在调试签名流程、离线生成签名等特殊场景下正确使用它。命令定位本地调试工具而非日常操作流程根据 docs/skopeo-standalone-sign.1.md 的定义skopeo standalone-sign是一个Debugging tool它“Sign an image locally without uploading”在本地为镜像签名而不上传。官方文档明确提醒This is primarily a debugging tool, useful for special cases, and usually should not be a part of your normal operational workflow; useskopeo copy --sign-byinstead to publish and sign an image in one step.即日常发布镜像时你不应该先手动签名再上传而应使用 skopeo-copy(1) 的--sign-by选项在复制镜像的同时一步完成签名。standalone-sign只服务于两类特殊场景调试签名机制验证 GPG 密钥、指纹、manifest 与签名之间的绑定关系是否符合预期离线/非交互签名镜像清单已落在本地文件系统希望在完全不接触网络的情况下生成签名。在 cmd/skopeo/main.go 的命令注册表中standaloneSignCmd()与standaloneVerifyCmd()一同被挂载到根命令下二者配套使用构成完整的“本地签名—本地验证”闭环。命令语法与三个位置参数命令的完整语法为skopeo standalone-sign [options] manifest docker-reference key-fingerprint --output|-o signature注意--output/-o是必填项下文会从源码验证这一点。三个位置参数的含义如下位置参数含义说明manifest镜像 manifest 文件的路径一个包含镜像清单的本地文件例如skopeo copy到dir:目录后生成的manifest.jsondocker-reference标识镜像的 docker 引用用于把签名“绑定”到该镜像身份如registry.example.com/example/busybox签名验证时会严格比对key-fingerprint用于签名的密钥身份即本地 GPG 私钥的完整指纹40 位十六进制而非短 Key ID位置参数的含义官方文档对三个参数的定义如下manifestPath to a file containing the image manifest —— 包含镜像清单的文件路径docker-referenceA docker reference to identify the image with —— 用于标识镜像的 docker 引用key-fingerprintKey identity to use for signing —— 用于签名的密钥身份。manifest文件与docker-reference是签名内容的一部分签名不仅覆盖 manifest 字节本身还同时绑定目标镜像引用这正是 containers-signature 规范的核心——一份签名必须同时绑定“清单摘要”和“镜像身份”防止签名被复制到其他镜像上冒用。选项详解参见 skopeo(1)全局选项如--policy、--insecure-policy、--registries.d放在子命令名之前本命令自身的选项如下。--help/-h打印命令的使用说明usage statement。--output/-ooutput file必填将生成的签名写入_output file。虽然文档将其列为选项但从源码看它是强制参数——缺少它命令直接报错退出见下文源码剖析。示例中签名文件的后缀常取.signature以示区分。--passphrase-filepath签名时使用的口令文件。官方文档给出明确警告The passphare to use when signing with the key ID from--sign-by. Only the first line will be read. A passphrase stored in a file is of questionable security if other users can read this file. Do not use this option if at all avoidable.要点只读取文件的第一行作为口令文件其余内容被忽略将口令明文存放在文件中如果其他用户可读则安全性堪忧除非万不得已不要使用该选项。对于未加密的测试密钥如cmd/skopeo/fixtures中配套的测试密钥可以完全不提供口令对于有口令保护的私钥交互式输入或 gpg-agent 是更安全的选择。仓库测试夹具中甚至准备了空口令文件cmd/skopeo/fixtures/empty.passphrase用于验证“空口令”场景下签名流程依然可用。实战示例从 manifest 到签名文件的完整流程官方文档给出的示例为$ skopeo standalone-sign busybox-manifest.json registry.example.com/example/busybox 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8 --output busybox.signature $下面按完整工作流展开讲解每一步。第一步获取镜像 manifest 文件standalone-sign不直接与远程仓库交互因此你需要先用其他手段把 manifest 落到本地。最方便的方式是使用skopeo copy配合dir:transport$ mkdir -p /tmp/busybox-dir $ skopeo copy docker://busybox:latest dir:/tmp/busybox-dir $ ls /tmp/busybox-dir/ 2b8fd9751c4c0f5dd266fcae00707e67a2545ef34f9a29354585f93dac906749.tar manifest.json此时/tmp/busybox-dir/manifest.json就是签名命令所需的manifest文件。仓库内 cmd/skopeo/fixtures/image.manifest.json 提供了一个可用于复现的 Docker schema 2 清单样例含config与三个layers每个 blob 都有mediaType、size与digest。第二步准备 GPG 私钥并确认指纹签名依赖本机 GPG 密钥环默认GNUPGHOME环境变量指向的目录中的私钥。可用gpg --list-secret-keys --with-fingerprint查看完整指纹$ gpg --list-secret-keys --with-fingerprint sec rsa3072 2024-01-01 [SC] 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8 uid [ultimate] Example User userexample.com注意必须使用40 位完整指纹。测试代码 cmd/skopeo/signing_test.go 中的常量也印证了这一点测试用完整指纹08CD26E446E2E95249B7A405E932F44B23E8DD43对应的短 Key IDE932F44B23E8DD43若在测试目录cmd/skopeo/fixtures中设置了GNUPGHOME即可用上述指纹直接对样例 manifest 签名。第三步执行签名$ skopeo standalone-sign \ /tmp/busybox-dir/manifest.json \ registry.example.com/example/busybox \ 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8 \ --output busybox.signature命令成功时没有任何标准输出静默成功并在--output指定的路径生成签名文件。测试 cmd/skopeo/signing_test.go 对成功路径的断言是out为空、错误为nil且生成的签名可用signature.VerifyDockerManifestSignature重新验证验证结果中的DockerReference与DockerManifestDigest均与输入一致。第四步本地验证签名配套命令生成的签名可用skopeo standalone-verify在本地校验$ skopeo standalone-verify \ /tmp/busybox-dir/manifest.json \ registry.example.com/example/busybox \ 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8 \ busybox.signature Signature verified using fingerprint 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8, digest sha256:20bf21ed457b390829cdbeec8795a7bea1626991fda603e0d01b4e7f60427e55输出会报告实际使用的验证指纹以及签名绑定的 manifest 摘要DockerManifestDigest。standalone-verify还支持--public-key-file指定公钥文件以及用逗号分隔的指纹列表或any表示信任公钥文件中的任意密钥作为key-fingerprints详见 docs/skopeo-standalone-verify.1.md。源码级剖析签名是如何完成的命令的完整实现位于 cmd/skopeo/signing.go核心流程清晰可读。参数定义与命令注册type standaloneSignOptions struct { output string // Output file path passphraseFile string // Path pointing to a passphrase file when signing }在standaloneSignCmd()cmd/skopeo/signing.go中注册两个 flag--output/-o短选项别名o帮助文本为 “output the signature toSIGNATURE”--passphrase-file帮助文本为 “file that contains a passphrase for the --sign-by key”。执行逻辑与调用链run()cmd/skopeo/signing.go按以下顺序工作参数校验len(args) ! 3 || opts.output 时直接返回Usage: skopeo standalone-sign manifest docker-reference key-fingerprint -o signature。由此可见位置参数恰好 3 个、且-o必须显式给出否则命令拒绝执行测试 cmd/skopeo/signing_test.go 用 6 组非法参数组合逐一验证了这一行为。读取 manifestos.ReadFile(manifestPath)文件不存在时返回Error reading path。初始化 GPG 签名机制signature.NewGPGSigningMechanism()来自go.podman.io/image/v5/signature包对应 go.mod 中声明的依赖失败时返回Error initializing GPG。这正是文档 NOTES 中所说“本命令面向 OpenPGP 本地签名”的落地实现。读取口令cli.ReadPassphraseFile(opts.passphraseFile)内部实现“只取第一行”的语义。生成签名调用signature.SignDockerManifestWithOptions(manifest, dockerReference, mech, fingerprint, signature.SignOptions{Passphrase: passphrase})—— 这一步同时把 manifest 字节、docker-reference 与密钥指纹绑定进签名内容。写文件os.WriteFile(opts.output, signature, 0o644)权限为0644写入失败时返回Error writing signature to path。测试 cmd/skopeo/signing_test.go 还验证了其余失败路径不存在的 manifest、空 docker 引用报 “empty signature content”、未知密钥指纹、以及写入目标不可写/dev/full均会以非零状态退出。指纹与摘要的可验证事实仓库测试夹具中的样例清单image.manifest.json与签名image.signature配合固定密钥指纹构成了一个可以反复复现的验证基准manifest 摘要sha256:20bf21ed457b390829cdbeec8795a7bea1626991fda603e0d01b4e7f60427e55签名私钥指纹08CD26E446E2E95249B7A405E932F44B23E8DD43集成测试 integration/signing_test.go 演示了完整的冒烟流程动态生成 GPG 密钥 →standalone-sign生成签名 →standalone-verify验证输出匹配正则^Signature verified using fingerprint ..., digest ...$。为什么日常推荐skopeo copy --sign-by而非 standalone-sign原文档在 DESCRIPTION 中明确建议日常场景使用skopeo copy --sign-by。这是因为一步到位复制镜像的同时完成签名与上传签名与镜像总是保持一致不存在“签了旧 manifest”的窗口期身份自动绑定--sign-by对应当前复制目标的destination-image生成 “simple signing” 签名见 docs/skopeo-copy.1.md无需手工维护 manifest 文件与引用的一致性错误面更小standalone-sign要求你先正确导出 manifest、再精确指定指纹与引用任何一步不一致都会导致签名与实际发布内容脱节。底层实现上copy的签名选项在 cmd/skopeo/utils.go 中定义--sign-byGPG 指纹、--sign-by-sq-fingerprintSequoia-PGP 指纹、--sign-by-sigstoresigstore 参数文件、--sign-by-sigstore-private-keysigstore 私钥。这些选项与--sign-passphrase-file配合使用但同一时刻只能指定一个签名方式且口令文件不存在会直接报错测试见 cmd/skopeo/utils_test.go。结论面向生产的发布签名一律走skopeo copy --sign-by只有当你在排查签名格式、研究签名绑定关系或需要完全离线地构造一份签名时才使用standalone-sign。使用边界与注意事项根据 docs/skopeo-standalone-sign.1.md 的 NOTES 章节还有两点必须明确仅适用于本地签名格式如 OpenPGP命令遵循 containers-signature(5) 规范由go.podman.io/image/v5/signature库实现其他签名格式可能在未来加入。当前版本面向 GPG/OpenPGP 本地签名。与 Docker Content TrustDCT无关本命令不会与 Docker Content TrustDCT生成的工件产生任何交互。DCT 是 Docker 生态中另一套基于 notary 的签名体系二者互不兼容不要混用。另外注意口令安全性--passphrase-file只读取文件第一行且口令文件若可被他人读取则形同虚设官方建议“能不用就不用”。签名文件权限固定为0644如对敏感环境有更严格的要求可在生成后自行收紧。相关命令与扩展阅读skopeo(1)全局选项--policy、--insecure-policy、--registries.d、--require-signed等与全部子命令总览skopeo-copy(1)日常签名推荐路径skopeo copy --sign-by的完整选项说明skopeo-standalone-verify.1.md配套的本地签名验证命令实现与测试cmd/skopeo/signing.go、cmd/skopeo/signing_test.go、integration/signing_test.go可复现的测试夹具cmd/skopeo/fixtures/image.manifest.json、image.signature、corrupt.signature、pubring.gpg、secring.gpg、empty.passphrase均在cmd/skopeo/fixtures/目录下。关于签名格式的完整规范containers-signature 的格式、字段与校验规则请查阅容器镜像签名规范文档containers-signature(5)它由本命令所依赖的go.podman.io/image/v5/signature库实现并遵循。【免费下载链接】skopeoWork with remote images registries - retrieving information, images, signing content项目地址: https://gitcode.com/GitHub_Trending/sk/skopeo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 skopeo standalone-sign 实战指南：不上传镜像，在本地为镜像清单生成 OpenPGP 签名
skopeo standalone-sign 实战指南不上传镜像在本地为镜像清单生成 OpenPGP 签名【免费下载链接】skopeoWork with remote images registries - retrieving information, images, signing content项目地址: https://gitcode.com/GitHub_Trending/sk/skopeo导读skopeo standalone-sign是 skopeo 提供的一个纯本地调试签名工具它只要求你提供一个镜像 manifest 文件、一个 docker 引用和一个 GPG 密钥指纹就能在不上传、不拉取镜像的情况下生成一份符合 containers-signature 规范的签名文件随后可用skopeo standalone-verify在本地完成校验。阅读本文后你将掌握该命令的完整语法、每个参数与选项的精确语义、底层签名调用链源码级并理解它与skopeo copy --sign-by的定位差异能在调试签名流程、离线生成签名等特殊场景下正确使用它。命令定位本地调试工具而非日常操作流程根据 docs/skopeo-standalone-sign.1.md 的定义skopeo standalone-sign是一个Debugging tool它“Sign an image locally without uploading”在本地为镜像签名而不上传。官方文档明确提醒This is primarily a debugging tool, useful for special cases, and usually should not be a part of your normal operational workflow; useskopeo copy --sign-byinstead to publish and sign an image in one step.即日常发布镜像时你不应该先手动签名再上传而应使用 skopeo-copy(1) 的--sign-by选项在复制镜像的同时一步完成签名。standalone-sign只服务于两类特殊场景调试签名机制验证 GPG 密钥、指纹、manifest 与签名之间的绑定关系是否符合预期离线/非交互签名镜像清单已落在本地文件系统希望在完全不接触网络的情况下生成签名。在 cmd/skopeo/main.go 的命令注册表中standaloneSignCmd()与standaloneVerifyCmd()一同被挂载到根命令下二者配套使用构成完整的“本地签名—本地验证”闭环。命令语法与三个位置参数命令的完整语法为skopeo standalone-sign [options] manifest docker-reference key-fingerprint --output|-o signature注意--output/-o是必填项下文会从源码验证这一点。三个位置参数的含义如下位置参数含义说明manifest镜像 manifest 文件的路径一个包含镜像清单的本地文件例如skopeo copy到dir:目录后生成的manifest.jsondocker-reference标识镜像的 docker 引用用于把签名“绑定”到该镜像身份如registry.example.com/example/busybox签名验证时会严格比对key-fingerprint用于签名的密钥身份即本地 GPG 私钥的完整指纹40 位十六进制而非短 Key ID位置参数的含义官方文档对三个参数的定义如下manifestPath to a file containing the image manifest —— 包含镜像清单的文件路径docker-referenceA docker reference to identify the image with —— 用于标识镜像的 docker 引用key-fingerprintKey identity to use for signing —— 用于签名的密钥身份。manifest文件与docker-reference是签名内容的一部分签名不仅覆盖 manifest 字节本身还同时绑定目标镜像引用这正是 containers-signature 规范的核心——一份签名必须同时绑定“清单摘要”和“镜像身份”防止签名被复制到其他镜像上冒用。选项详解参见 skopeo(1)全局选项如--policy、--insecure-policy、--registries.d放在子命令名之前本命令自身的选项如下。--help/-h打印命令的使用说明usage statement。--output/-ooutput file必填将生成的签名写入_output file。虽然文档将其列为选项但从源码看它是强制参数——缺少它命令直接报错退出见下文源码剖析。示例中签名文件的后缀常取.signature以示区分。--passphrase-filepath签名时使用的口令文件。官方文档给出明确警告The passphare to use when signing with the key ID from--sign-by. Only the first line will be read. A passphrase stored in a file is of questionable security if other users can read this file. Do not use this option if at all avoidable.要点只读取文件的第一行作为口令文件其余内容被忽略将口令明文存放在文件中如果其他用户可读则安全性堪忧除非万不得已不要使用该选项。对于未加密的测试密钥如cmd/skopeo/fixtures中配套的测试密钥可以完全不提供口令对于有口令保护的私钥交互式输入或 gpg-agent 是更安全的选择。仓库测试夹具中甚至准备了空口令文件cmd/skopeo/fixtures/empty.passphrase用于验证“空口令”场景下签名流程依然可用。实战示例从 manifest 到签名文件的完整流程官方文档给出的示例为$ skopeo standalone-sign busybox-manifest.json registry.example.com/example/busybox 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8 --output busybox.signature $下面按完整工作流展开讲解每一步。第一步获取镜像 manifest 文件standalone-sign不直接与远程仓库交互因此你需要先用其他手段把 manifest 落到本地。最方便的方式是使用skopeo copy配合dir:transport$ mkdir -p /tmp/busybox-dir $ skopeo copy docker://busybox:latest dir:/tmp/busybox-dir $ ls /tmp/busybox-dir/ 2b8fd9751c4c0f5dd266fcae00707e67a2545ef34f9a29354585f93dac906749.tar manifest.json此时/tmp/busybox-dir/manifest.json就是签名命令所需的manifest文件。仓库内 cmd/skopeo/fixtures/image.manifest.json 提供了一个可用于复现的 Docker schema 2 清单样例含config与三个layers每个 blob 都有mediaType、size与digest。第二步准备 GPG 私钥并确认指纹签名依赖本机 GPG 密钥环默认GNUPGHOME环境变量指向的目录中的私钥。可用gpg --list-secret-keys --with-fingerprint查看完整指纹$ gpg --list-secret-keys --with-fingerprint sec rsa3072 2024-01-01 [SC] 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8 uid [ultimate] Example User userexample.com注意必须使用40 位完整指纹。测试代码 cmd/skopeo/signing_test.go 中的常量也印证了这一点测试用完整指纹08CD26E446E2E95249B7A405E932F44B23E8DD43对应的短 Key IDE932F44B23E8DD43若在测试目录cmd/skopeo/fixtures中设置了GNUPGHOME即可用上述指纹直接对样例 manifest 签名。第三步执行签名$ skopeo standalone-sign \ /tmp/busybox-dir/manifest.json \ registry.example.com/example/busybox \ 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8 \ --output busybox.signature命令成功时没有任何标准输出静默成功并在--output指定的路径生成签名文件。测试 cmd/skopeo/signing_test.go 对成功路径的断言是out为空、错误为nil且生成的签名可用signature.VerifyDockerManifestSignature重新验证验证结果中的DockerReference与DockerManifestDigest均与输入一致。第四步本地验证签名配套命令生成的签名可用skopeo standalone-verify在本地校验$ skopeo standalone-verify \ /tmp/busybox-dir/manifest.json \ registry.example.com/example/busybox \ 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8 \ busybox.signature Signature verified using fingerprint 1D8230F6CDB6A06716E414C1DB72F2188BB46CC8, digest sha256:20bf21ed457b390829cdbeec8795a7bea1626991fda603e0d01b4e7f60427e55输出会报告实际使用的验证指纹以及签名绑定的 manifest 摘要DockerManifestDigest。standalone-verify还支持--public-key-file指定公钥文件以及用逗号分隔的指纹列表或any表示信任公钥文件中的任意密钥作为key-fingerprints详见 docs/skopeo-standalone-verify.1.md。源码级剖析签名是如何完成的命令的完整实现位于 cmd/skopeo/signing.go核心流程清晰可读。参数定义与命令注册type standaloneSignOptions struct { output string // Output file path passphraseFile string // Path pointing to a passphrase file when signing }在standaloneSignCmd()cmd/skopeo/signing.go中注册两个 flag--output/-o短选项别名o帮助文本为 “output the signature toSIGNATURE”--passphrase-file帮助文本为 “file that contains a passphrase for the --sign-by key”。执行逻辑与调用链run()cmd/skopeo/signing.go按以下顺序工作参数校验len(args) ! 3 || opts.output 时直接返回Usage: skopeo standalone-sign manifest docker-reference key-fingerprint -o signature。由此可见位置参数恰好 3 个、且-o必须显式给出否则命令拒绝执行测试 cmd/skopeo/signing_test.go 用 6 组非法参数组合逐一验证了这一行为。读取 manifestos.ReadFile(manifestPath)文件不存在时返回Error reading path。初始化 GPG 签名机制signature.NewGPGSigningMechanism()来自go.podman.io/image/v5/signature包对应 go.mod 中声明的依赖失败时返回Error initializing GPG。这正是文档 NOTES 中所说“本命令面向 OpenPGP 本地签名”的落地实现。读取口令cli.ReadPassphraseFile(opts.passphraseFile)内部实现“只取第一行”的语义。生成签名调用signature.SignDockerManifestWithOptions(manifest, dockerReference, mech, fingerprint, signature.SignOptions{Passphrase: passphrase})—— 这一步同时把 manifest 字节、docker-reference 与密钥指纹绑定进签名内容。写文件os.WriteFile(opts.output, signature, 0o644)权限为0644写入失败时返回Error writing signature to path。测试 cmd/skopeo/signing_test.go 还验证了其余失败路径不存在的 manifest、空 docker 引用报 “empty signature content”、未知密钥指纹、以及写入目标不可写/dev/full均会以非零状态退出。指纹与摘要的可验证事实仓库测试夹具中的样例清单image.manifest.json与签名image.signature配合固定密钥指纹构成了一个可以反复复现的验证基准manifest 摘要sha256:20bf21ed457b390829cdbeec8795a7bea1626991fda603e0d01b4e7f60427e55签名私钥指纹08CD26E446E2E95249B7A405E932F44B23E8DD43集成测试 integration/signing_test.go 演示了完整的冒烟流程动态生成 GPG 密钥 →standalone-sign生成签名 →standalone-verify验证输出匹配正则^Signature verified using fingerprint ..., digest ...$。为什么日常推荐skopeo copy --sign-by而非 standalone-sign原文档在 DESCRIPTION 中明确建议日常场景使用skopeo copy --sign-by。这是因为一步到位复制镜像的同时完成签名与上传签名与镜像总是保持一致不存在“签了旧 manifest”的窗口期身份自动绑定--sign-by对应当前复制目标的destination-image生成 “simple signing” 签名见 docs/skopeo-copy.1.md无需手工维护 manifest 文件与引用的一致性错误面更小standalone-sign要求你先正确导出 manifest、再精确指定指纹与引用任何一步不一致都会导致签名与实际发布内容脱节。底层实现上copy的签名选项在 cmd/skopeo/utils.go 中定义--sign-byGPG 指纹、--sign-by-sq-fingerprintSequoia-PGP 指纹、--sign-by-sigstoresigstore 参数文件、--sign-by-sigstore-private-keysigstore 私钥。这些选项与--sign-passphrase-file配合使用但同一时刻只能指定一个签名方式且口令文件不存在会直接报错测试见 cmd/skopeo/utils_test.go。结论面向生产的发布签名一律走skopeo copy --sign-by只有当你在排查签名格式、研究签名绑定关系或需要完全离线地构造一份签名时才使用standalone-sign。使用边界与注意事项根据 docs/skopeo-standalone-sign.1.md 的 NOTES 章节还有两点必须明确仅适用于本地签名格式如 OpenPGP命令遵循 containers-signature(5) 规范由go.podman.io/image/v5/signature库实现其他签名格式可能在未来加入。当前版本面向 GPG/OpenPGP 本地签名。与 Docker Content TrustDCT无关本命令不会与 Docker Content TrustDCT生成的工件产生任何交互。DCT 是 Docker 生态中另一套基于 notary 的签名体系二者互不兼容不要混用。另外注意口令安全性--passphrase-file只读取文件第一行且口令文件若可被他人读取则形同虚设官方建议“能不用就不用”。签名文件权限固定为0644如对敏感环境有更严格的要求可在生成后自行收紧。相关命令与扩展阅读skopeo(1)全局选项--policy、--insecure-policy、--registries.d、--require-signed等与全部子命令总览skopeo-copy(1)日常签名推荐路径skopeo copy --sign-by的完整选项说明skopeo-standalone-verify.1.md配套的本地签名验证命令实现与测试cmd/skopeo/signing.go、cmd/skopeo/signing_test.go、integration/signing_test.go可复现的测试夹具cmd/skopeo/fixtures/image.manifest.json、image.signature、corrupt.signature、pubring.gpg、secring.gpg、empty.passphrase均在cmd/skopeo/fixtures/目录下。关于签名格式的完整规范containers-signature 的格式、字段与校验规则请查阅容器镜像签名规范文档containers-signature(5)它由本命令所依赖的go.podman.io/image/v5/signature库实现并遵循。【免费下载链接】skopeoWork with remote images registries - retrieving information, images, signing content项目地址: https://gitcode.com/GitHub_Trending/sk/skopeo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考