OpenPubkey vs SignPath

OpenPubkey binds a user or workload identity established through OpenID Connect to a public key, so the identity can sign messages or artifacts. A PK Token represents control of an OIDC identity and its related private key at a particular time, provided the verifier trusts the identity provider. The project lists Google, Azure/Microsoft, Okta, OneLogin and Keycloak as compatible without changes to those providers; however, its client and verifier currently create and verify tokens from Google for users and GitHub for workloads. Current workload identity use requires GQ signatures. For user identity, they are unnecessary when the PK Token is not public. GQ signatures allow the identity provider’s signature to be stripped from an ID Token while preserving proof of that signature, preventing use against OIDC resource providers. OpenPubkey says it needs no additional certificate authority because the OpenID Provider fulfills that role. Public PK Tokens can reveal claims from an OIDC ID Token, potentially including a name or email address. The project is free under the Apache 2.0 license and is a Linux Foundation project; its repository says it is being prepared for version 1.0. The project directs technical questions to GitHub issues and offers a community Slack channel.

SignPath provides code signing and software integrity controls for builds and releases. Its format-aware signing covers executables, packages, installers, containers, scripts, manifests, SBOMs, and configuration files. Before trusting a release, it can verify source repositories, branches, build systems, approvals, and CI/CD context. SignPath can produce signed, machine-readable attestations, including SLSA provenance, validation summaries, and signed SBOMs. Listed integrations include plugins and REST API connections for GitHub Actions, GitLab, Jenkins, Azure DevOps, and TeamCity. SignPath says private keys remain in FIPS-compliant hardware security modules and are never exposed or shared. Role-based controls determine who can sign which artifacts and with which certificate. Signing records include the user, file, certificate, policy, and result; reports can be exported, with optional WORM-style log archiving. Deployment options are SaaS, self-hosted, or hybrid. The free Open Source Code Signing plan has eligibility conditions: projects must be actively maintained and released, use an OSI-approved open source license, and have no proprietary components.