AG-UI .NET SDK NuGet 包签名实战：基于 Azure Key Vault 与 GitHub OIDC 的发布签名链路

人工智能AI Agent【免费下载链接】ag-uiAG-UI: the Agent-User Interaction Protocol. Bring Agents into Frontend Applications.项目地址https://gitcode.com/gh_mirrors/agu/ag-ui点击查看免费下载本文是 AG-UI 仓库 .NET SDK 发布流程中 NuGet 包**作者签名author signing**机制的完整技术指南。它讲解 AGUI.* 系列 NuGet 包如何在发布工作流的publish-dotnet作业中、以 pack → SIGN → verify → push 的缝隙方式被 DigiCert 代码签名证书签名且全程依赖 Azure Key Vault 硬件安全模块HSM与 GitHub OIDC 联邦身份不保存任何长效密钥。读完本文你将掌握该签名链路的设计动机、开启步骤、底层调用过程、上线前的五步配置清单以及签名配置在仓库中的具体实现位置。签名链路总览pack 与 push 之间的一道缝隙AG-UI 的 .NET SDK 以五个 NuGet 包对外发布AGUI.Abstractions、AGUI.Formatting、AGUI.Protobuf、AGUI.Client、AGUI.Server发布入口是仓库根目录的 .github/workflows/publish-release.yml。签名发生在该工作流publish-dotnet作业publish-release.yml 第 1359 行起中位置恰好卡在打包与推送之间pack → SIGN (this seam) → verify → push也就是说dotnet pack产出的*.nupkg先被就地签名再经dotnet nuget verify校验最后才dotnet nuget push上传到 nuget.org。这个顺序保证了「推上去的一定是已签名的包」。签名使用DigiCert 代码签名证书其私钥以不可导出non-exportable、RSA-HSM的形式存放在Azure Key Vault中由NuGetKeyVaultSignTool工具配合GitHub OIDC完成签名——整个链路不存储任何长期有效的秘密long-lived secret。私钥全程不离开 HSM签名本质上是 Key Vault 内的一次keys/sign操作。缝隙默认是惰性的inert by default这是该设计最值得注意的一点在把SIGNING_PROVIDER变量显式设为keyvault之前这条签名缝隙什么都不做发布行为与未接入签名时完全一致。因此这部分 CI 代码可以安全地在基础设施Key Vault、证书、角色授权就绪之前就合入主干不会破坏既有发布流程。这一点在源码中体现得十分直白工作流的签名相关步骤全部用if: vars.SIGNING_PROVIDER keyvault条件门控见 publish-release.yml 第 1544-1590 行变量未设置时这些步骤整体跳过。作者签名 ≠ 仓库签名 ≠ 程序集强命名需要区分三件常被混淆的事仓库签名repository signaturenuget.org 在推送时总会自动附加自己的仓库签名这是平台行为与本机制无关。作者签名author signature本文所述缝隙添加的正是这种签名它携带发布者身份CNTawkit, Inc.使包在 nuget.org 上显示为 signed。程序集强命名strong-naming仓库中的 sdks/dotnet/AGUI.snk 配合SignAssembly/AssemblyOriginatorKeyFile见 sdks/dotnet/Directory.Build.props属于 DLL 内部的程序集标识机制与 NuGet 作者签名完全无关保持原样不动。一个佐证是 CI 测试步骤显式传入-p:SignAssemblyfalse见 publish-release.yml 第 1419 行即测试编译不启用强命名而打包产物才启用——二者路径互不干扰。如何开启在 nuget 环境上配置变量与密钥开启签名的唯一入口是在仓库的nuget环境Settings → Environments →nuget即publish-dotnet作业声明的environment: nuget见 publish-release.yml 第 1373 行上设置SIGNING_PROVIDERkeyvault并补充下表配置NameKindNotesSIGNING_PROVIDERvarkeyvaultAZURE_CLIENT_IDsecretApp RegistrationclientID —— 按文档记录截至 2026-07-01 已在nuget环境配置AZURE_TENANT_IDsecretDirectorytenantID —— 已配置AZURE_SUBSCRIPTION_IDsecret存放 vault 的订阅 —— 已配置AZURE_KEY_VAULT_URLsecret例如https://cpk-signing-kv.vault.azure.netCODE_SIGNING_CERT_NAMEsecretvault 中的证书名例如code-signingvault URL 和证书名本身不是凭据但依然以secret形式存放目的是让它们不进入提交到仓库的工作流文件和公开的 CI 日志。认证走的是联邦OIDC不存储 client secret。Preflight半配置状态不可能发布破损包工作流中专门有一个Preflight — validate signing configuration步骤publish-release.yml 第 1513-1540 行。只要SIGNING_PROVIDER非空且非none它就会逐项检查五个 secret 是否齐全若SIGNING_PROVIDER不是keyvault直接报Unknown SIGNING_PROVIDER并退出若五个 secret 任一缺失则以::error::形式显式列出缺失项并令运行失败。也就是说一个配置到一半的环境无法带着残缺配置把未签名或签名失败的包推出去——失败发生在签名工具深处之前且错误信息可直接指导运维补齐配置。签名如何工作四步底层流程从源码可以完整还原SIGNING_PROVIDERkeyvault时签名缝隙的每一步OIDC 登录 Azureazure/loginactionpublish-release.yml 第 1544-1550 行用作业的 OIDC token作业声明了id-token: write见第 1376 行换取 Azure 登录态使用的是 App Registration 上环境作用域的联合凭据federated credential其 subject 精确为repo:ag-ui-protocol/ag-ui:environment:nuget。这就是为什么签发环境必须与作业的environment: nuget一致——分支/ref 作用域的凭据会静默登录失败。铸造 Key Vault 数据平面令牌az account get-access-token --resource https://vault.azure.net生成一个短生命周期的数据平面访问令牌随后立即Write-Output ::add-mask::$token将其脱敏见 publish-release.yml 第 1568-1570 行再通过--azure-key-vault-accesstoken参数传给签名工具。这是唯一不依赖秘密的认证路径——托管身份managed identity与 client-secret 模式在 GitHub runner 上都不适用。逐个签名 nupkgNuGetKeyVaultSignTool sign对artifacts/nuget/下每个*.nupkg执行签名工具一次只签一个文件因此源码中用循环遍历见 publish-release.yml 第 1572-1584 行。关键参数包括--file-digest sha256SHA-256 摘要--timestamp-rfc3161 http://timestamp.digicert.com与--timestamp-digest sha256使用 DigiCert 时间戳服务的 RFC 3161 时间戳--azure-key-vault-url与--azure-key-vault-certificate指定 vault 与证书名--azure-key-vault-accesstoken传入第 2 步的短命令牌。*.snupkg符号包被有意排除在作者签名之外循环只筛选.nupkg扩展名这一点在工作流注释中明确说明。签名验证门禁dotnet nuget verify ${pkg} --all对每个包做完整校验publish-release.yml 第 1588-1602 行——若包未签名、或签名无法链接到受信根发布在此失败不会进入推送。通过验证后才轮到dotnet nuget pushpublish-release.yml 第 1610-1625 行主包推送到https://www.nuget.org/api/v2/package若存在符号包则另行推送到 v3 index。推送之后还有最长 900 秒的可见性轮询确保新版本真正出现在 nuget.org 的 flat container 上才继续后续的 tag 与 Release 创建。上线前的配置清单五步完成全部授权签名涉及多个角色的协作文档明确划分了职责Azure/订阅管理员完成第 1-2 步仓库管理员完成第 3 步nuget.org 组织管理员完成第 4 步之后任何人触发第 5 步即可发布。1. 为 CI 身份授予 Key Vault 访问权。App Registration即AZURE_CLIENT_ID在 vault 上需要两个角色——Key Vault Crypto User负责签名Key Vault Certificate User负责读取证书SP_OID$(az ad sp show --id AZURE_CLIENT_ID --query id -o tsv) VID$(az keyvault show --name cpk-signing-kv --query id -o tsv) az role assignment create --role Key Vault Crypto User \ --assignee-object-id $SP_OID --assignee-principal-type ServicePrincipal --scope $VID az role assignment create --role Key Vault Certificate User \ --assignee-object-id $SP_OID --assignee-principal-type ServicePrincipal --scope $VID2. 配置环境作用域的联合凭据。由于作业使用environment: nugetApp Registration 需要一条 subject 精确为repo:ag-ui-protocol/ag-ui:environment:nuget的联合凭据issuer 为https://token.actions.githubusercontent.comaudience 为api://AzureADTokenExchange。若误配成分支/ref 作用域登录会静默失败不易排查。3. 设置nuget环境的密钥与变量。用 gh CLI 按上文表格补齐Rag-ui-protocol/ag-ui gh secret set AZURE_KEY_VAULT_URL --env nuget --repo $R --body https://cpk-signing-kv.vault.azure.net gh secret set CODE_SIGNING_CERT_NAME --env nuget --repo $R --body code-signing gh variable set SIGNING_PROVIDER --env nuget --repo $R --body keyvault4. 在 nuget.org 注册证书。导出公钥证书并在ag-ui-protocol组织→ Manage → Certificates 下登记az keyvault certificate download --vault-name cpk-signing-kv --name code-signing \ --file agui-codesign.cer --encoding DER⚠️执行强制是全账号、立即生效的一旦有任何证书登记到所有者名下此后每一次推送都必须使用已登记证书完成作者签名否则会被拒绝。因此这一步必须与签名 CI第 3 步和版本升级第 5 步一起落地——不要提前登记否则中间任何一次未签名发布都会被 nuget.org 拒收。5. 版本升级并发布。nuget.org 的版本不可变immutable已签名的包必须以新版本号发布。在 sdks/dotnet/Directory.Build.props 中统一 bump 共享的VersionPrefix当前仓库值为0.0.6发布签名版本时需再递增例如0.0.6→0.0.7。一次 bump 会带着签名重新发布全部五个包——这五个包由 Directory.Build.props 第 18 行 的IsPackable条件圈定AGUI.Abstractions、AGUI.Formatting、AGUI.Protobuf、AGUI.Client、AGUI.Server。可选操作将旧的未签名版本从列表下架unlist引导使用者迁移到签名版本。为什么这张 DigiCert 证书符合 nuget.org 要求nuget.org 接受一张作者签名证书需要同时满足几个条件证书链能追溯至Microsoft Trusted Root Program中的根DigiCert 是成员带代码签名 EKUExtended Key UsageRSA ≥ 2048本仓库使用的证书为 RSA 3072并携带有效的RFC 3161 时间戳。所签发的 DigiCert 代码签名证书全部满足。另外在 nuget.org 上增删证书需要2FA为证书登记环节提供了额外的账号安全层。小结从 sdks/dotnet/docs/signing.md 出发结合 .github/workflows/publish-release.yml 与 sdks/dotnet/Directory.Build.props 可以完整还原 AG-UI .NET SDK 的 NuGet 作者签名设计一条默认惰性、按需开启、以 OIDC 短命令牌驱动 Key Vault HSM 签名、以dotnet nuget verify兜底的发布缝隙。对想要为自家 NuGet 包接入作者签名的团队而言这套「DigiCert 证书 Azure Key Vault RSA-HSM GitHub OIDC Preflight 门禁」的组合是一个可复制的参考模板——尤其是缝隙默认惰性、可先行合入与证书登记强制立即生效、必须与 CI 和版本升级同步落地这两条经验能显著降低接入风险。赞分享人工智能AI Agent【免费下载链接】ag-uiAG-UI: the Agent-User Interaction Protocol. Bring Agents into Frontend Applications.项目地址https://gitcode.com/gh_mirrors/agu/ag-ui点击查看免费下载相关推荐Dangerzone 发布流程实战从 PGP 签名标签、资产签名到 GitHub 草稿发布的最后一哩路Dangerzone 发布流程实战从 PGP 签名标签、资产签名到 GitHub 草稿发布的最后一哩路 本文以 Dangerzone 仓库的发布文档 rele应用安全SpacetimeDB 自托管 JWT 签名密钥轮换实战Azure Key Vault 与多主机编排指南SpacetimeDB 自托管 JWT 签名密钥轮换实战Azure Key Vault 与多主机编排指南 导读 本文围绕 SpacetimeDB 自托管场景下数据库关系型数据库后端Turso 的 Windows 代码签名实践基于 Azure Artifact Signing 的 Authenticode 签名与 CI 集成Turso 的 Windows 代码签名实践基于 Azure Artifact Signing 的 Authenticode 签名与 CI 集成 本篇技术指南数据库嵌入式数据库关系型数据库上一篇Lutris游戏更新机制5个简单步骤自动检测和安装游戏补丁与DLC的完整指南下一篇Swift基础语法快速入门The Swift Summary Book第一章详解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考