What to know

  • A new trusted publisher must complete a successful publication within 48 hours.
  • Previously validated configurations are exempt from the expiry rule.
  • Changing the publisher identity starts a new validation window.

Validation is tied to the publisher identity

GitHub announced changes to npm trusted publishing on October 2. A newly created trusted publisher configuration expires if it does not complete a successful publication within 48 hours. Configurations that have already published successfully are exempt. Changing the publisher identity starts a fresh validation window, while ordinary edits do not restart the timer.

Expired configurations remain visible but cannot publish. They do not count toward configuration limits, and other valid publishers are unaffected. The announcement also blocks OIDC token exchange for workflows triggered by issue_comment, alongside the existing restriction on pull_request_target. Supported triggers include push, release and workflow_dispatch. These changes limit which configured identities and workflow events can obtain publishing credentials.

Source: GitHub: Unvalidated npm trusted publishing configurations now expire

Analysis: An unused configuration is still an authority record

Trusted publishing links a package to an external workflow identity. That reduces reliance on a long-lived registry token, but the configuration itself remains a grant of authority. If the intended workflow is never exercised, the registry has less operational evidence that the configured identity represents a functioning publication path. Expiry narrows the period in which that unvalidated grant remains usable.

Repository and workflow names also need ownership controls outside the registry. A publisher configuration can be syntactically correct while pointing to a workflow that an organization no longer maintains. Teams should record the repository owner, workflow file and environment associated with each package. A successful first publication establishes that the path works; it does not eliminate the need to review later transfers or permission changes.

The event restriction addresses another boundary. A workflow triggered by a comment receives input from a different interaction than a controlled release. Publishing authority should follow the release process the organization intends to trust. Reusing a convenient event for both routine collaboration and credential issuance can make the effective permission boundary harder to understand.

The first release needs an explicit schedule

Maintainers creating a new trusted publisher should plan the first successful publication within the validation window. A release that depends on pending approvals, unavailable reviewers or an unfinished build may need the configuration created later in the process. If it expires, the team should inspect the configuration status and establish a new valid publishing path through the supported controls.

Continuous integration records should distinguish an authorization failure from a packaging or test failure. A workflow can build the correct artifact and still be unable to obtain a registry credential. Clear error classification helps maintainers resolve the actual problem without replacing trusted publishing with an unnecessarily broad persistent token. Release documentation should describe who can change the publisher identity and who verifies the first publication.

After validation, the normal questions of artifact integrity and release review remain. A valid publisher can publish an unwanted package if its workflow is compromised or its release inputs are not checked. The October change closes a specific gap around unused configurations and restricted triggers. It complements review of repository access, build dependencies and the exact artifact sent to npm.

Sources & further reading

  1. GitHub: Unvalidated npm trusted publishing configurations now expire

Factual statements are grounded in the linked material. Interpretation and illustrative examples are Byte Watchr analysis. Vendor claims are identified as claims, rather than independent testing.

Software supply chainsDigital identity

The event date records the source announcement or documented operation. The coverage edition groups recent developments and is separate from the publication date. Actual publication is recorded above.

Corrections policy · About this byline