Replies: 88 comments 160 replies
-
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Очень круто! |
Beta Was this translation helpful? Give feedback.
-
|
Copying some feedback here from our Slack discussion:
Additionally, see #174508 for some impact from the expiry and automation token removal. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
From https://docs.npmjs.com/trusted-publishers
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. |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
@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/ |
Beta Was this translation helpful? Give feedback.
-
I am also very curious if this will be solved before deprecating classic tokens |
Beta Was this translation helpful? Give feedback.
-
|
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
✅ 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
✅ 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.
❓ This one is rough, there is currently an unsolved "Enterprise" usecase here that I will outline in "Missing Pieces" below.
✅ 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.
✅ Yessss. Thank you. Forcing 2FA for everyone is the single biggest win out of all of these, if you run Make everyone have secure phishing resistant 2FA, and then force everyone to use it 💯
❓ 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 PiecesLet'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 WayOnce 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 nameThis 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:
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 Trusted Publishing should set up and enforce github environment usageCurrent 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 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 activeCurrently 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 The Enterprise Usecase and Other OIDC ProvidersThese 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
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 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") |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
@MarshallOfSound we are also going to be impacted by the inability to authenticate between CircleCI and NPM for publishing private packages. Your suggested workaround:
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? |
Beta Was this translation helpful? Give feedback.
This comment has been minimized.
This comment has been minimized.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
@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 |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
@IchordeDionysos trusted publishing provides a stealable short-lived token too, so no, it wouldn't. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
I believe the shai-hulud attack exfiltrated a token from a workflow, which would work the same way for OIDC. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. 
|
Beta Was this translation helpful? Give feedback.
-
|
@43081j @voxpelli can you help us with a scenario where a workflow without 2fa challenge on approval can be compromised/hacked and insecure? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks for this post. Some questions about To be able to run Right now, the
How will this be impacted by these changes? The github blog post does not address this issue. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
I am also wondering about this. I use |
Beta Was this translation helpful? Give feedback.
-
|
You're correct that The transition will be handled transparently by the CLI, so you can continue using Let us know if you have specific concerns about your CI/CD setup that we should consider. |
Beta Was this translation helpful? Give feedback.
-
|
I'm happy to hear that -- those tokens make me nervous! |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
@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) 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! 😅 |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Only if you happen to be on github.com or gitlab.com using shared hosted runners and hence can enable Trusted Publishing1. 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
Footnotes |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Phew, this would have been a huge burden for my team. Thanks for this clarifying thread. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Hey guys I have a question about the classic tokens deprecation: Will this deprecation affects Github Packages authenticated with PAT - Personal Access Token(classic) as well? In Github Packages documentation, they enforce that has just this type of authentication: 
I'm using this type of authentication for some private packages and I'm not sure if this deprecation will affect my workflows. |
Beta Was this translation helpful? Give feedback.
-
|
Just a heads up guys if anyone is using any type of ai to create scripts
they are giving the bad npm tools without understanding the supply chain
attack claude code gave me a bad package and now i have 2k sychost running
and gotta dump my whole 300gb and 3 new transactions on my wallet 2 zcash
gone 27 dollars in eth gone this am
…On Fri, Oct 31, 2025, 10:10 AM Lucas Pimenta ***@***.***> wrote:
Hey guys I have a question about the classic tokens deprecation:
Will this deprecation affects Github Packages authenticated with PAT -
Personal Access Token(classic) as well?
In Github Packages documentation, they enforce that has just this type of
authentication:
image.png (view on web)
<https://github.com/user-attachments/assets/50771de7-f7fd-4fd5-8da1-570f6551691f>
I'm using this type of authentication for some private packages and I'm
not sure if this deprecation will affect my workflows.
—
Reply to this email directly, view it on GitHub
<#174507 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BING55QZ7BLDOGME7NATHE332NUWZAVCNFSM6AAAAACHJT4IZ2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOBTHA4TEMA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
We have migrated all of our various actions to use OIDC, but now our nightly automation around |
Beta Was this translation helpful? Give feedback.
-
|
We have same problem with |
Beta Was this translation helpful? Give feedback.
-
|
Subject: Great initiative on the npm Security Improvement Plan Hi team, Thanks for sharing this detailed post and for proactively focusing on the security of the npm ecosystem. As a developer, supply chain security is a top concern, and it's great to see you addressing it head-on. I've read through the proposed plan, and I'm particularly supportive of the initiatives around [mention a specific part of the plan you like, e.g., enhancing 2FA enforcement or improving package integrity checks]. This seems like a strong and necessary step forward. I have a couple of clarifying questions to better understand the rollout: What is the expected timeline for these changes? Will they be rolled out in stages? Regarding the [mention another specific part, e.g., "new publishing verifications"], could you share a bit more about how this will impact the daily workflow for developers? For instance, what will the experience be like if a package fails one of these new checks? One suggestion I'd like to offer is [add a brief suggestion or area you think they missed, e.g., "to also consider providing more tools for automated dependency auditing within CI/CD pipelines"]. Overall, this is a very welcome direction. I appreciate the team's transparency and the chance to provide feedback. Looking forward to these improvements! |
Beta Was this translation helpful? Give feedback.
-
What's the point in asking AI to comment for you? |
Beta Was this translation helpful? Give feedback.
-
|
You’ve raised some great points: Timeline & rollout: The changes will indeed be rolled out in stages to minimize disruption. We’ll start with smaller opt-in phases (for example, with early adopters or specific package categories) before expanding to the broader ecosystem. We’ll be sharing a detailed timeline and milestones in an upcoming update post. Publishing verification workflow: The new publishing checks are designed to add security while keeping developer experience smooth. If a package fails a check, the CLI and web interface will provide clear error messages and guidance on how to resolve the issue (e.g., fixing signature mismatches or reauthenticating for 2FA). We’ll also include documentation and examples for common scenarios before rollout. Your suggestion: Great point about CI/CD dependency auditing — that’s definitely an area we’re exploring further. Our goal is to make it easier for developers to automate and monitor dependency integrity as part of their continuous delivery pipelines. We’re really glad to hear your support for stronger 2FA enforcement and improved package integrity checks. Your input helps shape how we prioritize and communicate these updates. |
Beta Was this translation helpful? Give feedback.
-
|
Stop posting AI generated comments! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Top-Dev1219, We’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team. You can read our updated Code of Conduct and the announcement for more details. Thank you for helping us maintain an authentic and beneficial space for everyone. |
Beta Was this translation helpful? Give feedback.
-
|
I'm fine with TOTP. I totally dislike using passkeys. |
Beta Was this translation helpful? Give feedback.
-
|
Is supporting GitHub reusable workflows on the list? I spent a few hours fighting with publishing because reusable workflows were not supported and it isn't documented (explicitly) that they are not supported. Here is a sample publish workflow that works fine with manual runs and release triggers (assuming you generate a release with a non-default token), but not with reusable workflows.
name: ' 🚀 Publish: Publish to NPM (automatic)'
on:
release:
types:
- published # will only trigger if you use an app token or PAT when creating the release.
workflow_dispatch:
inputs:
ref:
type: string
description: 'The git ref (branch or tag) to publish'
required: false
workflow_call:
# note this flow won't work until NPM adds support for reusable workflows
inputs:
ref:
type: string
description: 'The git ref (branch or tag) to publish'
required: true
permissions:
contents: read
id-token: write
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
with:
ref: ${{ inputs.ref || github.ref }}
- uses: actions/setup-node@v6
with:
node-version: 24
registry-url: 'https://registry.npmjs.org'
- run: npm ci
- name: Publish Package
run: npm publish
env:
NPM_CONFIG_PROVENANCE: trueIf I am reading the docs right, according to Using OpenID Connect with reusable workflows - GitHub Docs, NPM needs to check a combination of Current NPM Trusted Publisher setup: 
Request: add ability to add multiple optional workflows that can call |
Beta Was this translation helpful? Give feedback.
-
|
In a sense reusable workflows are supported just not in the way you (and I) probably first expected or had hoped. I made a sketch of that in https://github.com/orgs/community/discussions/174507#discussioncomment-14723818 and also requested there to make this more clear in the docs but that has not happened so far. And, yes, I also think one of the things missing is that more than one workflow can be defined as Trusted Publisher. The current workaround is awful. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! I had missed your comment. I guessed that adding the the name of the caller workflow would work, but that wasn't really an option in my case. I thought about using |
Beta Was this translation helpful? Give feedback.
-
|
If workflows had Terribly hacky, but it would get the job done. |
Beta Was this translation helpful? Give feedback.
-
|
I wasn't able to find where the output from a workflow gets passed to the |
Beta Was this translation helpful? Give feedback.
-
|
Output isn't passed in event payloads. That is why I showed the artifact method to pass data between them as an alternative. |
Beta Was this translation helpful? Give feedback.
-
|
Are granular tokens going to receive more updates? I understand that support for cli ( Comparing with GitHub Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
We have work in progress to enable cli management for granular tokens. We intended to ship it soon in this quarter. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, thanks for the information. Is there a deadline here (env of Nov/start of Dec)? |
Beta Was this translation helpful? Give feedback.
-
|
It's safer for me to say early December. |
Beta Was this translation helpful? Give feedback.
-
|
I have just finished migrating my 3rd repository to a Trusted Publisher. It is a painful experience since it isn't clear why things would be failing: 
Some clean documentation on what is needed to publish using a Trusted Publisher would be very helpful. Most of the documentation is out of date. Do you have any influence on the docs? This one is out of date: Generating provenance statements | npm Docs. It says npm |
Beta Was this translation helpful? Give feedback.
-
|
@Jason3S I'm having the same problem here, and there is an existing issue opened related to that: npm/cli#8730 |
Beta Was this translation helpful? Give feedback.
-
|
tl;dr; Trusted Publishing: I'm using Trusted Publishing (OIDC) from GitHub Actions for the I noticed that packages published via Trusted Publishing don't show up when querying the registry search API with
One concrete example package is Questions:
Thanks for your help and for the work you're doing on supply-chain security and provenance. |
Beta Was this translation helpful? Give feedback.
-
|
I'm currently blocked from migrating to Trusted Publisher until it supports org-wide setup. This deadline you gave us is insanity. |
Beta Was this translation helpful? Give feedback.
-
|
For a setup like yours, the best solution currently probably is to manually generate and store a token every 90 days (~4 times per year). Not nice, but until npm figures out something better, that seems to be the best. |
Beta Was this translation helpful? Give feedback.
-
|
Yea i will do that and then i will hack my own account to fuck the system who brink no security but mirage or use another registry. i had enough of them |
Beta Was this translation helpful? Give feedback.
-
|
Trusted publishing is the one of the most effective counter measures we can adopt as an industry against the types of attacks we have seen in the NPM ecosystem. Besides getting rid of (pre-/post-)install scripts. We should be solving security threats from multiple angles. |
Beta Was this translation helpful? Give feedback.
-
|
Token management is the responsibility of the person who creates it, the same as a a password. |
Beta Was this translation helpful? Give feedback.
-
|
In the OpenJS Security Collab Space, we recently published a guide on secure npm publishing practices: “Publishing Securely on npm”. It includes sample repos and practical workflows that many open-source maintainers can adopt today. Below is the quick-reference table from the guide, comparing the three main publishing approaches: Quick Reference
Key takeaways from our analysis
Our focus in the guide is helping maintainers choose the publication model that fits both their project scale and their security posture today, while preparing for workflows that will become safer over time. Happy to discuss details or provide deeper examples if helpful. |
Beta Was this translation helpful? Give feedback.
-
|
This hasn't been explained well. But as much as I hate to admit it, the deprecation of TOTP aka Google Authenticator actually does make sense:
I'm just glad that 1password supports passkeys, so I don't have to change my workflow and buy deeply into particular OS ecosystems in order to participate. (*) Public/private key cryptography is involved too. Offhand I'm not sure if that's any additional defense against a proxy. But it doesn't matter, because it's sufficient that the browser remembers the domain and is not fooled into performing the passkey dance on a malicious phishing proxy site. |
Beta Was this translation helpful? Give feedback.
-
|
for once i agree with @ljharb the real problem was and still is the "post install" script. |
Beta Was this translation helpful? Give feedback.
-
|
Blocking post install has a lot of merit, but wouldn't attackers just move to carrying out their evils at runtime instead? |
Beta Was this translation helpful? Give feedback.
-
|
There is way less chance that runtimes will get anything interesting. |
Beta Was this translation helpful? Give feedback.
-
I don't know how much "meaningfully harder" it is I project the 2-hour tokens does slow down the worm spread significantly though (And trusted publishing is also a good move forward, but the github action ecosystem has known weaknesses too)
It's possible Runtime also has its compartimenting solutions as well |
Beta Was this translation helpful? Give feedback.
-
|
Two-hour sessions are a temporary measure I hope. Mandatory passkey use to actually publish if using a token obtained via |
Beta Was this translation helpful? Give feedback.
-
|
You can still create classic tokens by navigating to https://www.npmjs.com/settings/USERNAME/tokens/new They work too. They just aren't listed under your /tokens page. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe they still need the classic ones for internal tooling 😂 |
Beta Was this translation helpful? Give feedback.
-
|
I think it stopped to work :/ |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, looks like it is being redirected now to: /tokens/granular-access-tokens/new |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the note here! This link has been updated as well. Any tokens created with it are being removed as well. |
Beta Was this translation helpful? Give feedback.
-
|
@leobalter, please dont do that. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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!
Beta Was this translation helpful? Give feedback.
All reactions