Trusted publishing reduces the need for long-lived package credentials, but it still depends on a chain of TLS and signing trust. The pypa publishing action for PyPI used a certifi trust store that included the emSign root CA. The CA was revoked. Versions of gh-action-pypi-publish before 1.14.2 continued to bundle the stale trust material.
GitHub advisory GHSA-5xjx-3w67-w9x9 describes the issue as a revocation problem in the chain Sigstore uses for Trusted Publishing and Digital Attestations. The action's TLS trust store is part of the path that verifies an identity and submits a package artifact. If a revoked CA remains trusted by the client, a certificate that should fail can still be used to build a chain that the client accepts.
The advisory is about the publishing action, not a claim that every package published through it is compromised. The distinction is important. A stale trust anchor creates an opportunity for a party that can present a certificate under that anchor. It does not prove that a certificate was misused or that a specific package or attestation is invalid.
Why revocation is a build-system control
Certificate revocation is often treated as a browser problem. In a build pipeline, the client is the action container or runner. Its trust decisions are part of the software-supply-chain boundary. If a revoked root remains in the trust store, the action can accept a chain that the rest of the ecosystem has already rejected.
The action relies on Sigstore for identity-aware signing and attestations. A failure in TLS verification can undermine the confidence that the artifact was submitted to the intended service. The exact downstream effect depends on the action's request path, the certificate presented, and whether the attacker can intercept or redirect the connection. The advisory gives enough information to treat the trust-store update as security-relevant without inventing a specific compromise.
This is also a pinning problem. Organizations often pin an action by tag, such as v1. A tag can move. A digest pin makes the reviewed code and its dependencies more stable, but the team still needs a process to update the pin when an advisory changes the trust store.
What to check in GitHub workflows
Search workflow files for pypa/gh-action-pypi-publish, including reusable workflows and composite actions that call it. Record the version or commit digest and the permissions granted to the job. A workflow with id-token: write can request a trusted-publishing identity, so its action version is more than a convenience dependency.
Update to the fixed release and pin the reviewed commit digest. Run a dry-run or test-publish path in a controlled repository before changing the production release workflow. Verify that the action can still obtain the expected identity, verify the certificate chain, and create the intended attestation.
Review the repository's release history for packages published while the old action was in use. The advisory does not establish compromise, so avoid making that claim. Instead, compare package digests, provenance records, approve-publish events, and repository audit logs. If the project's threat model requires stronger evidence, re-create attestations from a known-good build environment rather than assuming the old record is sufficient.
Detection and response
GitHub Actions logs can show the action version and whether the job requested an OIDC token. Preserve the run identifier, workflow commit, environment, package version, and publish timestamp. Do not rely only on the package index's successful upload as proof of a trusted path.
Rotate publishing credentials that the workflow could access, including package-index tokens or environment secrets that were exposed to the job. Review environment protection rules and who can approve a release. If a release job can be changed by an untrusted pull request, the certificate fix is not the only control that needs attention.
The lasting lesson is that supply-chain trust includes the trust store of the tool that performs the release. Open-source actions should be pinned, updated, and tested as production code. A revoked CA is a defect in that tool's assumptions even when no attacker is visible in the logs.