debug-js
propose for npm trusted publishing with OIDC
Based on what past few hours happened, I propose for using npm trusted publishing with OIDC, it has generally available on July 31. See this GitHub Changelog for more information.
cc @Qix-
Hi, while this is interesting, it wouldn't have prevented yesterday from happening. It also is, arguably, less secure, since if they had gained access to my GitHub instead, they would not only been able to poison the repo, but them perform a publish to npm, too.
With my npm login they would have been able to disable this entirely.
Hi @Qix-, I'm not the OP. While I understand your worries, using OIDC-based publishing is considered more secure and transparent than manual releases.
While indeed an attacker with access to your npm account could disable trusted publishing and create a manual release, such an event would be immediately obvious (if you were looking for it). As npm and the wider ecosystem is putting more effort into supply chains security, we'll get better ways to detect and protect against these kinds of things. With direct access to your npm account, they were also able to publish to npm, but these changes did not correspond to a visible changes on github, a workflow run, and a release.
For transparency the best thing to do would be having automated "builds" (even if it's just a test run or no-op) on github, which can be checked by anyone, and publishing them using trusted publishing. This links the published code to specific git commit / tag and github release.
OpenSSF (a Linux Foundation project) has more info on improving supply chain security for open source maintainers. More info can be found for instance at https://scorecard.dev/#learn-more and https://baseline.openssf.org/
I agree with @Qix- here. OIDC publishing wouldn't have prevented this due to the inherit broken package management ecosystem. All that is needed is to gain authenticated access to the npm account and boom. Using provenance does not prevent a malicious version from being published, it is more or less a cryptographic trust layer where the enduser still has to ensure that trust is not broken (eg. npm audit). The attacker can still publish without provenance because once a version was published with provenance, there is no enforcement of not publishing without. Having real author signing such as Maven does with PGP (.asc) is afterall the most reasonable approach because then it is not even possible to publish. But all those current solutions in the npm ecosystem are trust-after-publish not prevent-unauthorized-publish.
So yeah, as a nice-to-have trust-layer you can add the provenance OIDC stuff, but it won't prevent malicious versions from ever being published again🤷
I again would recommend to consider the move to trusted publishing. See also the recent shai-halud malware supply chain attack: https://sigh.dev/posts/ctrl-tinycolor-post-mortem/
Yes, trusted publishing at this time does not prevent supply chain attacks, but it allows for more fine-grained permissions and temporary tokens.
With high likelihood, github and npm will implement further protections against these attacks. A layered approach to security means you don't wait to install a stronger door until you have a better lock.
I'm aware of the shai halud attack, and I'm aware of what trusted publishing is. I still have problems with it from a security standpoint as I think it solves one problem and introduces another (or perhaps even multiple).
As I mentioned before, a github breach with OIDC means poisoned repo + poisoned publishing (whereas manual deployment means poisoned repo but no poisoned publishing). It also means that anyone with github maintainer status == publish access, which worsens the security posture on a number of my repositories, as a few of them have maintainers but still only allow me to publish. This is a measure I explicitly employ after the Jia Tan (xz) incident.
It also wouldn't have prevented the attack that hit me, either. I also don't think it would have stopped shai halud, given that many of the afflicted also had their github tokens leaked. Perhaps someone can correct me on that. The attack that hit me would have been thwarted by u2f, which is now enabled on my npm account.
Npm has confirmed with me that they're adding more security measures but they didn't specify what nor when. Ultimately, without better security primitives on npm's side, not a whole lot can be done to secure publishing flows in a way that is hardened against attacks that will most certainly evolve over the coming months. The way I read Scott's post-mortem, it seems he feels he's in a similar boat.