开发工具CLI前端构建【免费下载链接】extension-createThe cross-browser extension framework.项目地址https://gitcode.com/gh_mirrors/ex/extension-create点击查看免费下载Extension.js本仓库即其源码的每一个发布版本都使用 Sigstore 进行无密钥keyless签名npm 包携带来源证明provenanceGitHub Release 附带 SLSA 证明文件。本文基于 docs/VERIFYING_RELEASES.md完整讲解为什么可以无密钥签名以及如何用npm audit signatures、gh attestation verify、slsa-verifier三步验证发布产物并结合本仓库的发布流水线源码.github/workflows/release-attest.yml、.github/workflows/publish-release.yml说明校验背后的实现细节。读完本文你将掌握如何审计项目依赖中 Extension.js 四个 npm 包的签名与来源证明、如何核对某个版本的 attestation 详情、如何验证 GitHub Release 上 tarball 与 SLSA 证明文件的对应关系以及新旧两种证明文件provenance.intoto.jsonl与multiple.intoto.jsonl各自对应的校验工具与参数差异。为什么可以无密钥签名Sigstore 信任模型官方文档首先解释了整个签名体系的设计前提Every Extension.js release is signed with Sigstore. Signing is keyless.所谓 keyless无密钥签名核心是不存在长期有效的私钥Sigstore 的Fulcio组件会为构建发布版本的 GitHub Actions 工作流签发一个短期证书short-lived certificate签名记录同时写入Rekor透明日志transparency log任何人都能追溯由于没有长期私钥npm、GitHub 或任何分发站点上都没有可泄露的签名密钥公共信任根public trust roots属于 Sigstore 本身下面所有校验工具都会自动为你获取这些信任根。这种设计把密钥管理问题转化为工作流身份 透明日志问题攻击者无法通过窃取某个长期密钥来伪造发布因为签名身份是每次构建临时产生的且记录公开可查。在本仓库的 docs/ASSURANCE_CASE.md 中这一机制被明确列为源代码仓库与发布包之间信任边界Trust boundary 5的保障发布工作流运行在 GitHub 托管的 runner 上配合 OIDC 发布与 Sigstore 来源证明同时它也是 CWE-494未经验证下载的代码的对策之一——npm 完整性哈希 包签名来源证明。校验 npm 包来源证明npm provenanceExtension.js 一共发布四个公共 npm 包发布范围在 docs/RELEASING.md 中列明源码目录npm 包名用途programs/extensionextensionCLI 元包聚合其余三个包programs/createextension-create独立的脚手架创建引擎programs/developextension-develop开发、构建、预览与打包programs/installextension-install浏览器运行时安装支持这四个包均以 npm provenance 发布。发布侧的证据在 .github/workflows/publish-release.yml 中工作流环境变量NPM_CONFIG_PROVENANCE: true第 29 行每个包的发布命令均带--provenance标志例如npm publish --access public --tag ${{ steps.validate.outputs.tag }} --provenance第 530–535、571–576 行四个包各有一次发布不读取任何 npm token而是通过 GitHub OIDC 可信发布trusted publishingid-token: write与 docs/RELEASING.md 中npm authentication: the workflow publishes through npm trusted publishing with GitHub OIDC的描述一致。审计项目内已安装的包在安装了这些包的任意项目里运行npm audit signatures输出中必须报告这四个包的 verified registry signatures已验证的注册表签名与 verified attestations已验证的来源证明。这一步直接校验node_modules中已安装产物的完整性是最快的日常检查手段。查看某个版本的 attestation 详情如需查看某一版本的来源证明内容例如 4.1.18npm view extension4.1.18 dist.attestations该命令输出该版本发布时的证明元数据包含签名的 build 信息等。此外npm 的包页面也会显示一个Provenance区块其中链接到构建该发布的确切工作流运行记录与 commit——也就是说你可以从包页面一路追溯到这个 tarball 是哪次 CI 运行构建出来的。校验 GitHub Release tarball除了 npm每个 GitHub Release 还会附带四个包的 tarball 和一份已签名的 SLSA 证明文件。官方文档特别强调两个关键事实Release 上的 tarball 与 npm 包字节完全一致The release tarballs have the same bytes as the npm packages发布工作流在上传之前会先对照注册表完整性哈希registry integrity hashes逐一核对它们。这两点在 .github/workflows/release-attest.yml 中有对应的实现细节subjects任务通过npm pack nameversion从注册表取回 tarball然后用npm view pkgver dist.integrity取期望值再以openssl dgst -sha512计算实际哈希两者不一致立即失败does not match the registry integrity。也就是说Release 资产在生成时就已被证明与 npm 分发的内容同源。使用方式从仓库的 Releases 页面下载 tarball 与对应版本的证明文件然后根据该 Release 上的证明文件名选择匹配的校验命令——这取决于该版本由哪条工作流签名。新版本provenance.intoto.jsonl用gh attestation verify较新的 Release 携带provenance.intoto.jsonl由release-attest.yml工作流配合 GitHub 的 attestation actionactions/attest-build-provenance签名。校验命令需安装 GitHub CLIgh attestation verify extension-X.Y.Z.tgz \ --repo extension-js/extension.js \ --bundle provenance.intoto.jsonl \ --signer-workflow extension-js/extension.js/.github/workflows/release-attest.yml参数说明extension-X.Y.Z.tgz替换为你实际下载的 tarball 文件名--repo extension-js/extension.js声明产物来源仓库防止跨仓库混淆--bundle provenance.intoto.jsonl指定本地下载的 Sigstore bundle 文件--signer-workflow extension-js/extension.js/.github/workflows/release-attest.yml将签名身份钉死到这条工作流文件避免任何工作流签名都能通过的宽泛校验。官方文档还说明如果不带--bundlegh attestation verify会直接从 GitHub 拉取同一份 attestation 进行校验——因为 GitHub 同时把证明存储在仓库的 attestation API 中对应release-attest.yml中attestations: write权限与Attest build provenance步骤。旧版本multiple.intoto.jsonl用slsa-verifier较早的 Release 携带multiple.intoto.jsonl由 SLSA GitHub generatorslsa-github-generator 可复用工作流签名。校验前先安装 slsa-verifier然后运行slsa-verifier verify-artifact extension-X.Y.Z.tgz \ --provenance-path multiple.intoto.jsonl \ --source-uri github.com/extension-js/extension.js两点注意事项官方文档明确强调命令必须打印PASSED才算通过必须使用--source-uri而不是--source-tag因为证明文件记录的 source ref 是main——attest 工作流并不在 tag 上运行用--source-tag会校验失败。从源码角度看这条历史差异的来龙去脉记录在 .github/workflows/release-attest.yml 的注释中旧的 slsa-github-generator 拒绝 commit 固定pin所以早期版本携带multiple.intoto.jsonl迁移到 GitHub 官方attest-build-provenanceaction按 commit 固定后新版本改带 Sigstore bundleprovenance.intoto.jsonl并且同一份证明同时保存在 GitHub 上因此两种校验方式带--bundle或不带都能验证同一个 tarball。背后的发布与证明流水线理解校验命令之后再看流水线本身会更容易把握证明从哪里来。发布流水线publish-release.yml发布由Release – Publish工作流驱动支持三条通道通道npm dist-tag说明stablelatest正式版需纯净 semver如4.1.33nextnext预发布需-next.*形式canarycanary静默发布自动版本号base-canary.run_number.short_sha不建 GitHub Release对 stable/nextCI 构建后生成 release notes、提交版本号、打vversiontag、创建 GitHub Release 与 Deploymentcanary 则全部跳过。发布时通过 OIDC 可信发布 --provenance整个过程不读取 npm token。证明流水线release-attest.yml该工作流与发布工作流刻意解耦decoupled from publish-release.yml on purpose由三个事件触发workflow_run发布工作流成功完成后触发常规路径releasepublished手动把草稿 Release 转为公开时触发workflow_dispatch手动为某个 tag 补签backfill例如gh workflow run release-attest.yml -f tagv4.1.17。其内部由四个任务串成resolve解析出要签名的 release tag拒绝 draft 状态subjects从 tag 自身的 package.json 读取四个包名等待 npm 复制完成后拉取 tarball用 sha512 对注册表 integrity 做逐字节核对再算出sha256sum作为证明的 subject 列表provenance用 OIDC 令牌调用actions/attest-build-provenance做 keyless Sigstore 签名把 bundle 以provenance.intoto.jsonl上传到 Releaseassets重新拉取 tarball、再次核对 integrity用gh attestation verify --bundle provenance.intoto.jsonl逐一验证后才把 tarball 上传到 Release。这个先传证明、后传产物的顺序是有意为之的保证任何失败都只会让 Release 停留在未评分或仅含证明的状态绝不会出现有 tarball 却没有证明的不可校验状态注释中提及 OpenSSF Scorecard 的 Signed-Releases 检查会据此评分。校验实践建议与常见注意点综合文档与仓库源码可以总结出几条可落地的操作要点日常依赖审计在项目里定期运行npm audit signatures确认四个 Extension.js 包均为 verified registry signatures verified attestations核对单个版本用npm view extensionversion dist.attestations查看来源证明再结合 npm 包页面的 Provenance 区块追溯到具体工作流运行与 commit验证 Release tarball先看该 Release 携带的是哪种证明文件——provenance.intoto.jsonl用gh attestation verify记得带--signer-workflow收紧签名身份multiple.intoto.jsonl用slsa-verifier verify-artifact用--source-uri而非--source-tag并确认输出PASSED新旧版本差异同一仓库的不同版本可能使用不同的证明格式与签名工作流务必按文件匹配命令不要拿新命令去验旧文件canary 与草稿 Releasecanary 通道不创建公开 Release草稿状态的 Release 不会被 attest 工作流处理会直接拒绝需要先公开再触发校验。延伸阅读docs/VERIFYING_RELEASES.md本文的原始依据文档docs/RELEASING.md发布通道、版本规则与 npm 可信发布细节docs/ASSURANCE_CASE.md将签名与来源证明置于整体安全模型中的论证.github/workflows/release-attest.ymlSLSA 证明与 tarball 上传的实现.github/workflows/publish-release.yml--provenance发布与 OIDC 可信发布的实现四个发布包的publishConfigpublic 访问与 npmjs 注册表可见于 programs/extension/package.json、programs/create/package.json、programs/develop/package.json、programs/install/package.json。赞分享开发工具CLI前端构建【免费下载链接】extension-createThe cross-browser extension framework.项目地址https://gitcode.com/gh_mirrors/ex/extension-create点击查看免费下载相关推荐CCX 发布产物完整性验证指南Sigstore 无密钥签名、cosign 校验与 Windows Authenticode 双重保障CCX 发布产物完整性验证指南Sigstore 无密钥签名、cosign 校验与 Windows Authenticode 双重保障 CCX 的正式 ReleAPI网关LLM 网关后端CCX 发布产物安全验证实战Sigstore keyless 签名与 Windows Authenticode 双重校验CCX 发布产物安全验证实战Sigstore keyless 签名与 Windows Authenticode 双重校验 本文围绕 CCXClaude /API网关LLM 网关后端release-it 发布 npm 包完全指南版本提升、发布校验、2FA 与 CI/CD 实战release it 发布 npm 包完全指南版本提升、发布校验、2FA 与 CI/CD 实战 在 release it https://link.gitco开发工具DevOps上一篇B站弹幕太吵用这个弹幕屏蔽词分享平台3 步找回清净下一篇TiXL 交互 Gizmo 指南在输出视口中直接拖拽操控三维对象创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
