Our Review Finds npm Alone Has a Native Human Gate Before Package Release

A bounded review of public documentation for RubyGems, npm and PyPI finds one meaningful divide in automated package publishing: npm alone describes a registry-native step that keeps an existing package release private until a maintainer approves it with two-factor authentication. All three registries can bind publication to a configured CI workflow using short-lived credentials. But trusted publishing alone can still send a release straight to users.

That distinction separates two jobs that are often grouped together. A workflow-bound identity establishes which automated process may upload a package. A release gate determines whether that authorized process can make a specific artifact public before a person reviews it. The controls can work together, but one does not imply the other.

npm’s staged-publishing flow separates submission from publication. A contributor or automated workflow uses npm stage publish to place a version in a staging area. A maintainer can inspect the staged package, including by downloading its tarball, and must explicitly approve it with 2FA before it becomes publicly available.

The boundary is not universal. npm says staged publishing is unavailable for a brand-new package; the package must already exist in the registry. The finding is narrower but still material: npm documents a human checkpoint for new versions of existing packages, not for every initial package registration.

All three registries document a way to exchange an identity from a configured CI system for a short-lived publishing credential. npm supports configured workflows from GitHub Actions, GitLab CI/CD and CircleCI. RubyGems binds a publisher to a GitHub repository and workflow. PyPI exchanges a configured workflow’s OIDC identity for a short-lived API token.

Those credentials reduce dependence on stored write tokens, but they do not establish that the resulting code is safe. PyPI explicitly says Trusted Publishing does not assert code safety or author trustworthiness. Its guidance also warns that people able to alter a registered publishing workflow may be able to change when or what it releases.

RubyGems presents a tag push as sufficient to release a configured gem. PyPI’s documented trusted-publishing path uploads directly to the main repository after its OIDC exchange. npm can also authorize direct publication if a maintainer enables that action for a trusted publisher. In each case, trusted publishing can be a direct-release mechanism rather than a human-review requirement.

A person can still be placed in the loop outside the registry. PyPI’s security guidance describes GitHub and GitLab environments with required or manual approvers. RubyGems documents an optional GitHub environment that can constrain who may publish. These are surrounding CI controls, not a documented registry-held staging state between upload and public availability.

The review found the clearest public provenance records at npm and PyPI. npm exposes a build environment, workflow run, source commit, build file and transparency-log entry. PyPI publishes per-file attestations that identify the Trusted Publisher identity used for an upload. The reviewed RubyGems trusted-publishing guide identifies the workflow and short-lived gem-scoped credential, but does not describe a comparable public attestation feed.

That provenance can help establish where a release came from, but it is not a complete record of how an incident unfolded. PyPI stores user events in account security history. RubyGems published a dated account of its May spam-publishing campaign, saying it paused registrations, removed responsible accounts and yanked more than 500 packages. The reviewed materials do not specify a shared, complete exportable forensic record or incident-response service level.

The registries also make different recovery and abuse controls visible. RubyGems advises revoking credentials and yanking affected releases. npm says deleting a token may take up to an hour to take effect. PyPI says it automatically revokes API tokens detected on public websites and requires verified email for new projects and uploads.

RubyGems is the only registry in this review with published numeric thresholds directly relevant to rapid automation: 100 signup requests per 10 minutes per client IP, and 400 successful gem pushes per hour. The reviewed npm and PyPI pages do not provide comparable numeric general publishing throttles, although PyPI’s verified-email rule adds a separate barrier to registration and upload.

This analysis covers official public documentation checked through September 16, 2026. An undocumented control may exist internally or arrive later. For now, the practical line is clear: workflow identity tells a registry which process may release; staging creates a chance to stop a particular release. Watch for native staging on first releases, comparable public provenance across ecosystems, and incident records that make containment visible as well as origin.