Our plan for a more secure npm supply chain

[leobalter]

We recently published a post about our plan to improve security on npm as a supply chain supplier and I'd love to gather everyone's feedback.

Please use this thread for general feedback. Other threads might be pinned as well as they get popularity as I want to keep free formatting for all.

Thanks!

[ljharb]

• on killing TOTP: https://github.com/orgs/community/discussions/174505
• on forced expiry: https://github.com/orgs/community/discussions/174506

[devid44555-web]

This is a really valuable initiative — npm security improvements are long overdue, especially with how [common])dependency attacks have become. Strengthening the supply chain not only protects developers but also builds more trust in the ecosystem. Excited to see how these changes roll out and impact package publishing in the coming months. Great work by the team.

[wesleytodd]

Copying some feedback here from our Slack discussion:

Ok, this is overall a good step, specifically disallowing non-2FA local setups and setting better defaults. It is still missing the workflow for 2FA in CI, it seems to limit ci publish to only trusted publishing (unless you want to deal with the toil of manually minting a token every week) which means we loose one existing option for a secure setup, and also need to request a fix for the missing identity on publishes.

So while it is moving in the right direction, my first optimistic read was anchored on the defaults and missed the whole bit that they are not actually addressing the ask for native 2FA workflows and even making one secure (albeit complicated to setup) workflow even harder since they dont have a proper api for minting tokens.

I think mainly these changes are good, they are just not complete. Adding first party support for the CI workflows to require 2fa as well is the main missing piece for me.

Additionally, see #174508 for some impact from the expiry and automation token removal.

[IchordeDionysos]

it seems to limit ci publish to only trusted publishing

As a package consumer, I would want to have every package on npm use trusted publishing, period. Not even allow, local publishing with 2FA or publishing with an expiring token.

Trusted publishing allows you to look into the exact commit and build pipeline that was used to build a package.

[wesleytodd]

Trusted publishing allows you to look into the exact commit and build pipeline that was used to build a package.

You have been able to do this for a long time without trusted publishing. The packument contains the commit it was released from. That is how things like npx reproduce work. Unfortunately it is not common that you can reproduce a build. Additionally, the provenance data is only kept as long as GHA keeps past builds (right now I think 90 days max). So you are not really getting much more from TP, and you are loosing forced 2FA because those are mutually exclusive today.

So while I think your goals are spot on, the implementation today of TP is drastically lacking for achieving said goals. So until those gaps are closed, a responsible maintainer with 2FA turned on is more secure than TP. Once the gaps are closed, I think we can recommend it but that doesn't mean there is anything to gain from removing local publish.

Instead we should focus our attention on increasing the reproducibility of builds and adding 2FA support in all the right places.

[voxpelli]

There’s also some still valid and unaddressed feedback in the discussion around the OIDC / Trusted Publishing launch, such as eg my comment there: https://github.com/orgs/community/discussions/161015#discussioncomment-14419367

[dasa]

From https://docs.npmjs.com/trusted-publishers

Self-hosted runners are not currently supported but are planned for future releases.

Is this support planned to be released before deprecating legacy classic tokens?

We use GHES with self-hosted runners in our publishing workflow, and would like to switch OIDC / Trusted Publishing. It would be a breaking change for us to no longer be able to use legacy classic tokens with no ability to use OIDC instead.

[voxpelli]

Feel free to join in on ossf/wg-securing-software-repos#90 to discuss the general principles and guidance for adding new platforms to Trusted Publishing enabled registries (goes beyond npm)

[saquibkhan]

@voxpelli it is not related but i want to share with you and others for visibility on npm oidc APIs (currently supports github/gitlab) - https://api-docs.npmjs.com/

[rbarker-dev]

Self-hosted runners are not currently supported but are planned for future releases.

I am also very curious if this will be solved before deprecating classic tokens

[MarshallOfSound]

There's a lot of good feedback elsewhere in these discussions but I want to make my take public outside of the slack as well.

I'm going to go through the bullet points in the github blog post and then provide my own additional requests at the bottom.

Current Planned GitHub / NPM Action Items

Deprecate legacy classic tokens.

✅ This is good, get rid of them. Scoped and granular tokens are intrinsically more secure and the developer pain of "ah darn I gotta run npm login again" is worth the security win IMO.

Deprecate time-based one-time password (TOTP) 2FA, migrating users to FIDO-based 2FA.

✅ Again, this is great. I had this as an item in an unpublished blog post that NPM should do. It effectively moves NPM from "2fa" to "phishing resistant" 2fa, which if in place 2 months ago would have prevented several of the initial compromises we saw hit the npm registry due to phishing attacks against maintainers (some of whom had 2FA and got their TOTP mitm'ed).

To be clear, this is going to be quite annoying for so many people. Not in the least me, Electron publishes ~50+ packages all using TOTP codes (securely sent via http://github.com/continuousauth to github actions) that all need to be migrated to trusted publishing. But this is work we were going to do anyway because we'd already made our own conclusions about trusted publishing being the more secure future.

Limit granular tokens with publishing permissions to a shorter expiration.

❓ This one is rough, there is currently an unsolved "Enterprise" usecase here that I will outline in "Missing Pieces" below.

Set publishing access to disallow tokens by default, encouraging usage of trusted publishers or 2FA enforced local publishing.

✅ Finally, yes, thank you. Guiding developers towards the more secure option by default is a quick and easy win here that doesn't impact any existing package.

Remove the option to bypass 2FA for local package publishing.

✅ Yessss. Thank you. Forcing 2FA for everyone is the single biggest win out of all of these, if you run npm publish locally it shouldn't matter what token you have, there should be a final form of "step up" auth in this case 2FA. Will it results in some developers having to open a browser every time they publish? Yes. Is that the end of the world? No

Make everyone have secure phishing resistant 2FA, and then force everyone to use it 💯

Expand eligible providers for trusted publishing.

❓ This one is also rough, but not because I'm against the idea, I'm wary of the implementation. See the "other OIDC providers" bit in "Missing Pieces" below

Missing Pieces

Let's pretend that everything in the above list shipped, what are we still missing to have a secure and simple package publishing strategy that works for everyone who currently uses npm

Trusted Publishing should be One Way

Once you opt in to Trusted Publishing and publish your first release with it, that should be a one way choice only changeable in extreme cases with intervention from npm support. Currently just having access to a maintainers npm account effectively let's you perform a "downgrade" attack on them by removing trusted publishing and/or changing publishing settings. Once a package is published the Super Safe way, it should only ever be publishable that way.

Trusted Publishing should use repository ID not name

This is a common issue I see with github apps and other github integrations, I'm disappointed to see it from npm. By validating the owner name and repository name you are intrinsically creating the following issues:

• Typos / typo-squatting
• Race conditions when renaming
• Race conditions when transferring repos between orgs / to an org

The current UI in npmjs.org needs to be an actual dropdown of repositories using github oauth to provide a list and then internally it should validate the repository_id claim of the OIDC token not the repo slug as that is unsafe.

Trusted Publishing should set up and enforce github environment usage

Current GitHub environment usage for trusted publishing is a manual and optional step, in addition to the above once you have an oauth token for the users github account, set up the environment for them. Enforce the environment can only be used on the {DEFAULT_BRANCH} by default (user can change later if they want) and even give them a $CI_PROVIDER template file that consumes that environment in a safe way.

This should be a series of clicks in the UI, not a custom yaml file, a hand crafted environment and manually typing in repo org and name.

Trusted Publishing should disable all other legacy forms of publishing when active

Currently even with trusted publishing enabled, a compromised maintainer account with a TOTP mitm can still publish these packages. Having Trusted Publishing active should just make all other forms of publishing disabled, regardless of how much auth you provide. See Trusted Publishing should be One Way again for more reasoning.

The Enterprise Usecase and Other OIDC Providers

These two I don't have an answer for, but calling them out anyway. Enterprises use self hosted runners, even to publish open source packages, they also use CI systems that aren't github actions or gitlab. What's the story going to be for them, enterprises with self hosted CI (Jenkins, BuildKite, CircleCI, etc.) should still be capable of publishing packages safely without having to manually update a token every 7 days 🤔 I would like to see a plan for that.

[pimterry]

Once you opt in to Trusted Publishing and publish your first release with it, that should be a one way choice only changeable in extreme cases with intervention from npm support.

Trusted Publishing should disable all other legacy forms of publishing when active

While generally tightening this up is good, imo exclusive-use + one-way-only always is too much.

It's hard to know how people will use this and want to change their setups in future (especially as the ecosystem develops and new solutions to these issues appear), or will get stuck with broken setups, and all that will create extra support load for npm en route. HPKP is a good example of how this goes wrong. Mainly I worry hard limits like this will discourage people from enabling trusted publishing in the first place, since it makes it a much higher risk more complicated thing to enable.

Trusted publishing needs to work somehow for people maintaining just one package as a tiny sideproject, and people just testing it out and exploring, not just for large mature orgs who know what they're doing. Otherwise most packages will never use it, and we all know how many tiny packages maintained by individual hobbyists are powering the ecosystem.

There's plenty of good middle ground though: e.g. adding a delay for any changes (e.g. doesn't disable for 48 hours, maybe a week) and notifications allowing any maintainer of the package to block the change. That would significantly increase the challenge of a downgrade attack, which still making it possible for normal users to manage trusted publishing configs in a reasonable way.

Obviously any change like this should require 2FA auth anyway though... And if you can do a downgrade attack providing the password & 2FA, you could also just change the account's email, password & 2FA setup directly, in which case you can just do whatever you want (including legitimately talking to NPM support as the account owner)... Maybe the delay is the only solution for this extreme case, since at least that way the real owners have some warning & time to object before anything can happen.

It might also be interesting to explore a 'modification lock' approach (like https://en.wikipedia.org/wiki/Registrar-Lock for DNS) independent of just setting up Trusted Publishing - once all is good and you're happy, then you tell npm to make it extra hard to change these settings later, and enforce a 7 day delay/support request/visit to the NPM office/notarized letter from your head of state/whatever.

[3nprob]

What you are proposing results in that publishing can only practically be done from GitHub and GitLab architecture. There must be a compelling, proven, and established flow for self-hosted/third-party Trusted Publishing on npmjs before we should consider enforcing it across the NPM platform and community.

Ideally with a realistic timeline between announcement and enforcement (years or months, not weeks or days).

[MarshallOfSound]

What you are proposing results in that publishing can only practically be done from GitHub and GitLab architecture. There must be a compelling, proven, and established flow for self-hosted/third-party Trusted Publishing on npmjs before we should consider enforcing it across the NPM platform and community.

That is not what I am proposing in the slightest.

There is no reason why local publishes can't still be supported in a safe way in a world where Trusted Publisher is the *default, easy to use and bullet proof (which is what most of my feedback covers).

A developer should be able to run npm publish and provide username & password & webauthn based authentication, potentially additionally verify by additional validation via email verification in "suspicious" cases (country changes, lots of rapid publishes, etc.). But they should have to do that for every publish, not have a magic token that let's you publish from anywhere at any time which is the current world we live in.

The same system could theoretically be used by other CI providers, the npm publish job currently outputs a URL that the developer must authenticate the publish with. Your CI can just "pause" on that URL and you can provide the auth on your machine. Automated publishing requires a level of trust in the infrastructure that we can't just assign to everyone but I agree there should be a clear set of guidelines and requirements for onboarding new trusted OIDC roots beyond just GitLab and GitHub. I just don't see a world where self-hosted ever meets that bar, third party folks like CircleCI/BuildKit and such though I definitely want to see on this list. (Note: I called this out in "The Enterprise Usecase and Other OIDC Providers")

[MarshallOfSound]

It might also be interesting to explore a 'modification lock' approach (like https://en.wikipedia.org/wiki/Registrar-Lock for DNS) independent of just setting up Trusted Publishing - once all is good and you're happy, then you tell npm to make it extra hard to change these settings later, and enforce a 7 day delay/support request/visit to the NPM office/notarized letter from your head of state/whatever.

Anything a developer has to opt in to will not be used. See: 2FA

If people wanted to be more secure at scale everyone on the registry would voluntarily have secure 2FA right now, but they don't.

At a certain point we need to make the trade-off as an ecosystem: Security of the ecosystem must be the priority and developer UX can take a back seat in some areas. Baseline registry security should never be optional or opt-in

[spiralman]

@MarshallOfSound we are also going to be impacted by the inability to authenticate between CircleCI and NPM for publishing private packages. Your suggested workaround:

Your CI can just "pause" on that URL and you can provide the auth on your machine.

Is hardly universally possible, and probably not simple to implement in any CI system.

Realistically, it seems like this change, without flexible CI support, is more likely to cause developers of packages to revert to manual publishing from laptops, which is almost certainly more fraught for supply-chain attacks than publishes from a CI system.

Would it not be possible to just add a "generic" trusted publisher type, where the NPM administrator enters an expected issuer and public key for the JWT, for a particular package or NPM organization? This is how AWS and GCP work to grant access to, e.g. CI tools without each CI tool having to be registered with them.

If you're uncomfortable with this for public packages (i.e. you are concerned developers will use this to "hack around" your restrictions and not use proper key management), you could restrict these generic trusted publishers to just private NPM packages, which would at least meet our needs.

In lieu of this, can you at least provide a date for CircleCI to become a trusted publisher?

[leobalter]

Here is a new post with changes we are applying first as part of this program. Please take a look and thanks for the continued feedback, as it is helping us doing some fine adjustments to the new measures we are implementing.

[voxpelli]

why not publish the underlying technology pieces and processes so that teams could adopt this themselves

@twesterhuys The Trusted Publishing concept was pioneered by PyPI and described and documented by the OpenSSF Working Group on Securing Software Repositories in eg the Trusted Publishers for All Package Repositories document.

Making oneself technically able to become a Trusted Publishing platform is the fairly easy part – getting oneself onboarded as a valid platform by npm is the harder part.

Ultimately there should be guidance on this, I opened ossf/wg-securing-software-repos#90 to track it

[twesterhuys]

@voxpelli that's great news and many thanks for the background - would be nice if GH more explicitly mentiones this in their docs rather then to referring this much more vaguely. Good to hear that what I assumed was the problem (onboarding rather then tooling/standards) to be the bottleneck and many thanks for crystilizing this in the issue.

[ljharb]

@IchordeDionysos trusted publishing provides a stealable short-lived token too, so no, it wouldn't.

[MarshallOfSound]

trusted publishing provides a stealable short-lived token too, so no, it wouldn't.

This doesn't cover the full picture, trusted publishing provides significantly shorter lived tokens and they aren't on end-user machines. Stealing them would require compromising the entire privileged build environment, not just phishing a user which is what happened multiple times last month. You can't phish an OIDC token, and you can't steal access from a human or a compromised developer machine if they didn't have it to begin with.

[ljharb]

I believe the shai-hulud attack exfiltrated a token from a workflow, which would work the same way for OIDC.

[DNin01]

I think npm accounts should be as important as... I don't know, Apple developer accounts. Great to see that security updates are being made!

[ericcornelissen]

If you're going to force people to generate new tokens by forcing (short) expiry windows, at least make it easy for them to regenerate tokens using the previous configuration. As someone who has been using short-ish expiry windows already, this has been by far my biggest frustration with it - this feature has been long overdue...

If a token of mine expires, I probably need one with the same granularity to replace it, so give me that option. If not, I think many developers will just generate overly permissive tokens because it's easier than specifying one package per token (again, I have considered this but luckily I don't publish that often). I believe this would contribute significantly to preventing attacks as a leaked token for one project wouldn't allow publishing all the package maintainer's other tokens.

See also my earlier piece of feedback: npm/feedback#1088

[grochoge]

Please clarify the scope for this. It's linked from the main GitHub page; is it only for NPM or is it for everyone?

I believe there are some things that you can do with classic access tokens that you cannot do with fine-grained tokens

[voxpelli]

The specifics in the post is for the npm registry in particular (which is owned by GitHub)

The concept of Trusted Publishing comes from OpenSSF / PyPi and GitHub has supported such publishing to such platforms for years.

See eg. https://repos.openssf.org/trusted-publishers-for-all-package-repositories for an overview and description of the general principles and reasoning behind the “Trusted Publishing” concept

[43081j]

One thing we seem to be skipping over:

GitHub environments should have an option to require 2fa

All of these npm changes are fine if there's 2FA in the trusted workflow.

Currently, you can already bind a trusted workflow to an environment in that it must be run through that to be considered trusted.

In reality the only reason anyone is complaining about the changes so far is because such a flow doesn't exist.

The flow should basically go like this:

• create a release (however you prefer, e.g. tags)
• workflow is triggered against an environment
• environment waits for approval (already possible)
• in order to approve, maintainer must complete 2FA
  • similarly, changing the workflow settings (like removing approvals constraint) should need 2FA

Admittedly this isn't an npm change but given how we're all being pushed to use GitHub for publishing, it's a very important feature to make the whole picture work.

[voxpelli]

Totally agree, I mentioned this here: https://github.com/orgs/community/discussions/161015#discussioncomment-14419367

What I would want:

Multiple reviewers are possible for branch protection rules, feels like it should even more so be possible for deployment environments.

[saquibkhan]

@43081j @voxpelli can you help us with a scenario where a workflow without 2fa challenge on approval can be compromised/hacked and insecure?

[43081j]

if someone compromises an action right now, they may be able to capture a github token.

lets say they manage to do that, and the token has the permissions necessary to commit and to trigger a release (whether it be by a tag or by a GitHub release, or whatever git-based trigger).

if they got this far, they can probably use the same token to either disable the approval constraints or to approve the workflow (assuming you bound the workflow to an env that requires approvals).

if we could require 2FA when approving workflows, that means even a stolen token can't approval a release at the end of it. they'd need to pass through 2FA to approve it, or to disable the approval constraint.

right now, someone could get this far with a compromised token and successfully publish a package as far as i understand

(some of the recent incidents were compromised, overly permissive GitHub tokens acquired through workflows. so we have to assume that will happen again)

as far as i can see, most other concerns are moot if this gets solved. people who are unhappy about losing TOTP, are only unhappy because they're still publishing manually right now - and the only reason they're publishing manually is because they can't enforce 2FA on publish approvals.

[shajz]

Hi, thanks for this post. Some questions about npm login and its use of legacy tokens:

To be able to run npm ci on projects that use private scoped packages on the npm registry, we have to run npm login to be authenticated and gain access to those packages (otherwise we get a 404).

Right now, the npm login command generates legacy tokens.

When you run npm login, the CLI automatically generates a legacy token of publish type. For more information, see About legacy tokens.

How will this be impacted by these changes? The github blog post does not address this issue.

Thanks!

[kategengler]

I am also wondering about this. I use npm login in order to change a dist-tag (to promote a stable release to our lts tag).

[leobalter]

You're correct that npm login currently generates legacy tokens. We've planned for this - when we complete the classic token revocation, npm login will automatically switch to receiving compatible short-lived session tokens that expire after a reasonable session duration. Your existing workflows for accessing private scoped packages with npm ci will continue to work without any changes required on your end.

The transition will be handled transparently by the CLI, so you can continue using npm login as you do today. We'll share full implementation details in our upcoming release announcements over the next few weeks.

Let us know if you have specific concerns about your CI/CD setup that we should consider.

[kategengler]

I'm happy to hear that -- those tokens make me nervous!

[arcanis]

@leobalter will that work with older versions of the npm cli ? Does that change how 3rd party package managers should interact with the registry endpoints ? Yarn implements yarn npm login as well - do we need to change our implementation ?

[shajz]

@leobalter thanks for the reply! A few more questions:

What will be the default granular token options? (duration / read-only vs read-write / organizations scopes)
I'm assuming we'll need to update npm if we need special options? Currently, npm login gives us a non expiring token with read-write with private org access, which is very convenient from a developer standpoint. I fear it won't be that easy after the new solution is deployed.

Every developer in my company will be impacted and I will have to tell them what to do once their classic tokens are revoked. I'm anticipating a big ball of frustration and would like to know how to avoid it! 😅

[jacobtb23]

Thanks for the post. Related specifically to the Shai Hulud attacks I saw mentioned in the article that there are controls in place to prevent packages with Shai Hulud IoC's from being published. Can you detail that for me? We are trying to assess if NPM/Github has this under control or if we need to build out additional checks for Shai Hulud effected packages (Search for IoC's ourselves).

[std4453]

Our company has its own CI system and we do some npm package publishing using long-live tokens. We would like to migrate to Trusted Publishing, yet documentation says that it does not have wide support, nor is there any clear directions on how to implement Trusted Publishing for custom CI systems.

With long-live tokens going to be revoked in mid-November, does that mean our only option is to npm login every time before CI tasks? How does that suppose to work along with 2FA, and do we have examples on that?

[fmal]

Will long-lived classic tokens with read-only scope (not able to use for publishing) will also be revoked? They're useful for granting read-only access to packages in a private scope and don't pose security risk like publish tokens.

[twesterhuys]

Only if you happen to be on github.com or gitlab.com using shared hosted runners and hence can enable Trusted Publishing¹. If you happen to use GitHub or GitLab self hosted runners or other CI providers this is currently not supported and it's unclear when this will be the case. Docs used to say self hosted runners are not supported. It seems to have been updated to now say

Self-hosted runners are not currently supported but are planned for future releases.

Footnotes

1. https://docs.npmjs.com/trusted-publishers ↩

[mex]

But isn't the OIDC flow and Trusted Publishing specifically for write access tokens? It doesn't seem to solve the case of read-only access to private NPM packages. Requiring manual token rotation every 90 days is akin to begging people to implement (less secure?) workarounds to somehow automate that process.

[twesterhuys]

Yes, ignore my comment. The current wording is not entirely clear, I think? To me it reads like the new limits only apply to tokens with write scopes:

Starting in mid-October, all newly created write-enabled granular access tokens for npm will have:

[mex]

You are right, it does only apply to tokens with write scopes. If you create a new granular access token for read-only access, you can still set the expiry time to for example 2100-01-01.

[denolfe]

Phew, this would have been a huge burden for my team. Thanks for this clarifying thread.

[Farati1]

Now we're talking

…

On Mon, 20 Oct 2025, 19:52 My building, ***@***.***> wrote: I get what you saying and I totally understand about the packages cuz even charm is affected right now through a third party representative that's causing degradation and I guarantee you it'll probably be through one of them packages or something On Mon, Oct 20, 2025, 8:37 AM Tom Boutell ***@***.***> wrote: > If post-install goes away, malicious versions of modules can do roughly as > much harm at runtime instead, no? > > This is very long term, but blue-skying here for a second, what would > really help is the ability for the installer of the module (not the > developer of the module) to declare what actions they want that module to > be able to take. > > A restriction on a direct dependency of the project would take precedence > on a restriction of a sub-dependency, etc. So if a direct dependency of the > project is locked down by the project developer to, for instance, no > filesystem or network access, then no sub-dependency gets that privilege > when invoked by that module either. > > Obviously that's a pretty massive ask involving major changes to > JavaScript runtimes. Just thinking through what it would really take to > prevent certain classes of attacks entirely at the package infrastructure > level. > > I think it is more likely that we will get an ecosystem with fewer > sub-sub-sub-dependencies. We'll see more "standard libraries" and > "batteries included frameworks." > > — > Reply to this email directly, view it on GitHub > < #174507 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/BING55WUPPA7KIKFYS2XX5D3YTJRBAVCNFSM6AAAAACHJT4IZ2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINZSHEZDCNI> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#174507 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BQ54RCLALS4HZ672JPBH6SL3YUOO7AVCNFSM6AAAAACHJT4IZ2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINZTGI2DKOA> . You are receiving this because you commented.Message ID: ***@***.***>

[kmalakoff]

I need some help finding a workflow that actually will work with these changes. I have 150 packages. My deployment process is:

1. process all my packages in topological order based on dependencies
2. upgrade all dependencies using ncu -u
3. run install in a loop until the latest versions are installed
4. run build, lint, depcheck, sort-package-json
5. run tests
6. and if all of these succeed publish

Then I repeat the cycle for the next level of dependencies topologically. I'm not using monorepos.

I have no idea how to do cascading, topological deployment using github actions. Does anyone have any suggestions?

[leobalter]

Right now the lifetime has been limited to 90 days maximum for all granular tokens with write access, the default is 7 days.

We have plans to eventually limit this lifetime to a 7 days maximum. I'm working on a plan that will enable users to migrate to better publishing options - such as trusted publishing - so you have proper alternatives to granular tokens.

[kmalakoff]

@leobalter I would love to use trusted publishing. After experimenting with it, just the act of going into over 80 npm package configurations, and linking them to GitHub repos and testing them is a huge one time effort. If there's any way that you can help make this a bulk process, that would be amazing.

I need to have something that can be run in topological order which is crucial to publishing in the right order and catching issues across modules. I currently do very exhaustive testing in my GitHub actions so my process is push changes to git up actions run exhaustive testing across many versions of node and operating systems to validate any major changes. After I get an all green, I start the publish process incrementally locally using topological, incremental publishing to catch any dependency issues that I might have missed. I'm really not sure how I can replicate this in github actions. It probably would require some sort of advanced scripting to push groups of jobs and wait for them to resolve and get published before starting another batch of deployments.

I would probably stick with the granular tokens until I can see some real world examples of advanced dependency-walking / topological publishing using trusted publishing

[jakebailey]

I hope no more changes are planned until all of these problems are solved. A 90 day rotation is workable (but annoying), but 7 days without any rotation API is pretty brutal when there are no alternatives for more advanced use cases than publishing a single package.

[ckohen]

@kmalakoff I recently built a fairly advanced topological publish script for discord.js.

It's in two pieces, the top level action, and the actual actions script which is fairly close to being useable by other monorepos.

It would work great with trusted publishing (and we could actually enable it if it for the main publishes if it weren't such a hassle) if we were able to specify multiple workflows (or more accurately, allow specifying a single workflow that can publish latest, and others which can publish tags). The main thing holding us back is actually that we deprecate old development tags, which isn't currently possible with trusted publishing.

[blimmer]

Agreed that the lack of a rotation API is a huge miss. Having to have a human go through the website every n days to update tokens is an unnecessary operational burden.

Trusted Publishing doesn't solve for needing a read-only token for private organization packages.

[happypoulp]

Do you have a date for CircleCI to become a trusted publisher ? November deadline is coming soon and having no news so far about support for it is not sending the right signal for this migration.

[ExplodingCabbage]

If all the major existing source forges and CI providers were being supported out of the gate, this would be a lot more defensible. Why aren't they? Is it even legal, under most jurisdictions' competition laws, to deploy this change without support for publishing through the majority of existing CI providers?

GitHub Inc has a monopoly in one market (the JavaScript package registry market; npm is basically the JavaScript package manager right now). It is using that monopoly to damage its competitors in other markets (the source forge and CI system markets) by having npm give GitHub's own products (GitHub and GitHub Actions) preferential treatment. That is a classic "abuse of dominance" case, no? Using your dominance in one market to force your users in that market to also go with your offering over your competitors' in an adjacent market is precisely the sort of conduct that competition law exists to stop.

Higher up in this discussion we see various commenters bemoan that this change makes it non-viable for them to keep using their current CI provider - CircleCI, for instance - for package publishing, and that they will have to cease using that provider as a result. I do wonder if that was in fact the entire point. And I also wonder if those competitors' lawyers - and perhaps some competition regulators - are going to quite justly take action against GitHub in response.

[wojpawlik]

Please upgrade https://github.com/actions/runner-images to use npm 11.5.1 before invalidating existing tokens. This way, existing --provenance users wouldn't need to change any code.

[datenreisender]

They still need to set their workflow as trusted publisher in the settings of the npm package. And that is only possible if they have exactly one workflow that can be triggered to lead to publishing.

[christianemanuelson]

In this first post you state you will

• Set publishing access to disallow tokens by default, encouraging usage of trusted publishers or 2FA enforced local publishing.
• Remove the option to bypass 2FA for local package publishing.

and it also said that you will only support "Granular tokens which will have a limited lifetime of seven days."
And now with the strengthening post
"Granular access tokens will have maximum expiration of 90 days" and you make no mention of requiring 2FA or removing the option to bypass.
But then I read this comment from two days ago saying that you still plan to move to 7 day token expiry eventually

Is 2FA is not yet required for local publishing?
Do you plan on requiring 2FA for local publishing in the future?
And what exactly does bypass 2FA for local package publishing mean? To me that means requiring 2FA and disallowing tokens like in option three here.

If this means that we are requiring 2FA for every publish for each package, then this is really going to ruin our intern's day.
@leobalter

[SleeplessByte]

I don't understand what the point was to ask for feedback if that feedback isn't used to ensure that we're not stuck. Seems like everything has been going ahead as mentioned given the announcement 2 weeks ago here: https://github.com/orgs/community/discussions/176828

Yeah great, our current tokens are not yet borked, but that doesn't help me when I need a new one for a new deploy machine. So I guess the stance is for us to figure it out, take the huge cost, or be vendor locked in GitHub/GitLab.

Please let us know where we can all send our invoices.

[SleeplessByte]

And of course the latest update has 0 indication on how long we'll need to deal with new system for self-hosted runners.

[sokcuri]

GitHub and npm don’t seem interested in user feedback at all, so I’m not sure why they opened this thread. Changes that favor a specific vendor will only invite legal repercussions.

These policies are being rolled out far too hastily, with no phased transition. Frankly, it comes across as pretty amateur. It feels like the response to past issues is simply to wipe everything away.

My suggestions:

• Restore support for the standardized TOTP method.
• Revert write-token expirations to the previous indefinite setting.
• Introduce a “Trusted Publish” label so package managers can use it to apply tiered security policies to packages.

[typed-sigterm]

npm/cli#8699 is blocking me from using trusted publishing

[rsmple]

Just delete post-install scripts.

I don't use anything that has such script. I look skeptically on such tools and try to replace them, even if it requires migration of the whole project to some other tools. This is "quality of life" we never asked for. I'm sure everyone who uses it - is able to to same things without post-install script.

---

How token lifetime limit could prevent recent attacks? Compromising the tokens and contaminating the supply chain took only a few hours to spread. The token lifetime should be less than 5 minutes? I don't see any working solution to the actual problem proposed.

The main reason of that: post-install scripts and email services, that allow phishing attacks to be so effective.

[riderx]

I agree so bad, jsr doesn’t have it and it’s okay

[leobalter]

For everyone following this thread, I've posted some updates for the plans thanks to all the feedback I received here.

Please continue providing feedback as we can continue improving our plans and making npm better and more secure!

[SleeplessByte]

Please provide an actual date for when self-hosted runners are fully supported or alternatively the invoice details so the gigantic amount of extra work everyone has to do until that's live can be covered.

"Looking ahead" doesn't pay the bills. We are humans too.

Edit: Apparently my reply has been removed from the posted update which had the exact same concern. Great move!

[meeech]

Hi. I'm Mitch, a dev over at CircleCI. I just want to assure people we are in conversation about getting approved as an npm trusted publishing option.
We are just as impacted as our customers.

[tkumark]

Hi We are currently on Bitbucket Cloud. We have been using Classic Token. Based on the article Classic Tokens will be disabled soon and we need to use Granular Access Token. It looks like write enable granular access token needs to updated every 90 days manually. Is there any ETA when OIDC be available for Bitbucket?

[mikew]

Is there a way to use Github actions to generate a new token? We could then use that as a jumping board to update a token in a CircleCI context.

[meeech]

I don't think you will have to do this. I'm in conversation with github, and I don't see any reason why we won't be able to get this done pretty quickly.

[Otr437]

No you cannot use GitHub as a jump point for new tokens that would be redundant in in in they can just capture the traffic and still inject maliciously

…

On Thu, Oct 30, 2025, 10:53 AM Mike Wyatt ***@***.***> wrote: Is there a way to use Github actions to generate a new token? We could then use that as a jumping board to update a token in a CircleCI context. — Reply to this email directly, view it on GitHub <#174507 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BING55RFQFKPO6ZUCRIPU5T32IQ6LAVCNFSM6AAAAACHJT4IZ2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOBSHAYDQMQ> . You are receiving this because you commented.Message ID: ***@***.***>

[riderx]

when there is stupid rules stupid solution will be found. We will all endup running a browser in a cloud to generate our token and put our password and 2fa in it. Because NPM team tough once again they where smarter than everyone