Yet in practice, only the big boys are allowed to become "Trusted Publishers":

> In the interest of making the best use of PyPI's finite resources, we only plan to support platforms that have a reasonable level of usage among PyPI users for publishing. Additionally, we have high standards for overall reliability and security in the operation of a supported Identity Provider: in practice, this means that a home-grown or personal use IdP will not be eligible.

How long until everyone is forced to launder their artifacts using Microsoft (TM) GitHub (R) to be "trusted"?

[1] https://docs.pypi.org/trusted-publishers/internals/#how-do-i...

As I'm not familiar with the npm ecosystem so maybe I'm misunderstanding this but it sounds like they removed support for local publishes (via a token) in favor of CI publishing using Trusted Publishing.

If that is correct, I thought this was discussed when Trusted Publishing was proposed for Rust that it was not meant to replace local publishing, only harden CI publishing.

> I think a lot of the pains here are self-inflicted on GitHub's part here

It is spelled 'Microsoft'.

What did you think would happen long term? I remember when that acquisition happened and there were parties thrown all around, MS finally 'got' open source.

And never mind feeding all of the GitHub contents to their AI.

"In its current form" is in context of NPM, where I think it's accurate.

Great to see PyPi taking a more reasonable path.

NPM has to decide between either being a friendly place for hobbyists to explore their passions or being the backbone for a significant slice of the IT industry.

Every time someone pulls/messes with/uploads malware to NPM, people complain and blame NPM.

Every time NPM takes steps to prevent pulling/messing with/uploading malware to NPM, people complain and blame NPM.

I don't think splitting NPM will change that. Current NPM is already the "100% use at your own risk" NPM and still people complain when a piece of protestware breaks their build.

If you are going to put up hurdles and give us extra jobs, you need to start paying us.

Alternatively, we can accept that there will be fewer libraries because some volunteers won't do the extra work for free. Arguably there are too many libraries already so maybe a contraction in the size of the ecosystem would be a net positive.

It's a bit more complicated than that. The ecosystem around node is just weird. It's not clear what role NPM wants to have.

Lots of people chase downloads on NPM. It's their validation, their youtube subscribers, or their github stars if you will. That's how they get job offers. Or at least they think they do, I don't know if it actually works. There's tons of good software there, but the signal to noise ratio is still rather low.

Given that, I'd rather get paid for including your software as a dependency to my software, boosting your downloads for a long time.

Just kidding, of course. On that last part. But it wouldn't surprise me the least if something like it actually happened. After all, you can buy stars on github just like on any other social media. And that does strange things to the social dynamics.

I agree with you here, it feels like management said: "well, we have to do SOMETHING!" and this is what they chose: push more of the burden on to the developers giving away stuff for free when the burden should be on the developers and companies consuming the stuff for free.

Not looking forward to the mandatory doxxing that would probably come along if this was introduced today.

Yes! I despise how the open source and free software culture turns into just free labour for freeloading million-dollar and billion-dollar companies.

The culture made sense in the early days when it was a bunch of random nerds helping each other out and having fun. Now the freeloaders have managed to hijack it and inject themselves into it.

They also weaponise the culture against the devs by shaming them for wanting money for their software.

Many companies spend thousands of dollars every month on all sorts of things without much thought. But good luck getting a one-time $100 license fee out of them for some critical library that their whole product depends on.

Personally I'd like to see the "give stuff to them for free then beg and pray for donations" culture end.

We need to establish a balance based on the commercial value that is being provided.

For example I want licensing to be based on the size and scale of the user (non-commercial user, tiny commercial user, small business, medium business, massive enterprise).

It's absurd for a multi-million company to leech off a random dev for free.

"Trusted Publishing" is just a term of art for OIDC. NPM can and should support federating with CI/CD platforms other than GitHub Actions, to avoid even the appearance of impropriety.

(It makes sense that they'd target GHA first, since that's where the majority of their users probably are. But the technique itself is fundamentally platform agnostic and interoperable.)

Yes. You cannot set up your own.

CLI publishing with TOTP 2FA worked fine until they broke it.

Wouldn't this just make the number of packages that can be targeted smaller? E.g. I publish a testrunner that needs to install Headless Chrome if not present via postinstall. People trust me and put the package on their allowlist. My account gets compromised and a malicious update is published. People execute malicious code they have never vetted.

I do understand this is still better than npm right now, but it's still broken.

There are a large subset of security problems that are solved by simply eliminating compilation steps typically included in "postinstall". If you want a more secure, more debuggable, more extensible lib, then you should definitely publish it in pure js (rather than, say, Typescript), so that there is no postinstall attack surface.

It also make it impossible to publish using CI, which is problematic for projects with frequent releases. And trusted publishing doesn't solve that if you use self-hosted CI.

Agreed on the "this needs to be Debian" part. If some of the most popular JS packages were available through the system package manager as normal *.deb packages, I think people would be more likely to build on top of stable versions/releases.

Stability (in the "it doesn't change" sense) is underrated.

The fact is that being Debian is boring, and JS (python/rust/...) is *cool*.

Give it a few more decades, hopefully it'll be boring by then, the same way, say, making a house is boring.

I think Java’s DNS namespacing is, at best, only a weak benefit to the supply chain security posture of Java packaging as a whole. I think it’s more that Java is (1) a batteries-included language, (2) lacks the same pervasive open source packaging culture that Python, Rust, JS, etc. have, (3) is much more conservative around dependency updates as a community, and (4) lacks a (well-known?) build time code execution vector similar to JS’s install scripts or Python’s setup.py.

(Most of these are good things, to be clear!)

The primary way supply chain issues in Java are addressed is the very simple way: You don't have a large supply chain.

You have one or two megalibraries that are like 20 years old and battle tested and haven't really changed in forever.

Then you have a couple specific libraries for your very specific problem.

Then, you pin those versions. You probably even run your own internal repo for artifacts so that you have full control over what code you pull in to your CI

But none of this actually prevents supply chain attacks. What it does is drastically lower their profitability and success.

Lets say you magically gain access to the Spring Boot framework's signing keys. You put out a malicious version that will drop persistent threats and backdoors everywhere it can and pulls out any credit card numbers or whatever it can find. The team behind Spring Boot takes like two weeks to figure it out, notify the breach, and take down the malicious code.

How many actual systems have even pulled that code in? Very few. Even a significant supply chain attack still requires significant luck to breach targets. In NPM land, this is not the case, and tons of things are pulling in the "latest" version of frameworks. You are much more likely to get someone to actually run your malicious code.

No, it does need help at the publishing side. Most places I know are not updating by default. Everything has a lock file. But the nx attack a few months ago happened because the VS Code extension for nx was always ran the @latest version to check for updates or something like that.

So yeah… people will always have these workflows which are either stupid or don’t have an easy way to use a lock file. So I’d sure as hell like npm to also take some steps to secure things better.

As far as I know, using a lock file with npm install is both the default behavior and also doesn’t randomly updates things unless you ask it to… though it’s definitely best practice to pin dependencies too

Its a false belief that distro based package management workflows are, or ever were, more secure. Its the same problem, maybe one step removed. Look at all the exploits with things like libxz

There was also the python 2.7 problem for a long time, thanks to this model, it couldn't be updated quickly and developers, including the OS developers, became dependent on it being there by default, and built things around it.

Then when it EOL'd, it left alot of people exposed to vulnerabilities and was quite the mess to update.

The robust and secure distro based package management workflow that shipped the libxz backdoor to everyone, and broke openssh key generation, and most of the functionality of keepassxc?

where do you get all these trusted people to review your dependencies from?

it can't be anyone, because you're essentially delegating trust.

no way there's enough trustworthy volunteers (and how do you vet them all?)

and who's going to pay them if they're not volunteers?

Never in a million years.

Rust's Cargo is sublime. System apt / yum / pacman / brew could never replace it.

Cargo handles so much responsibility outside of system packages that they couldn't even come close to replicating the utility.

Checking language versions, editions, compiling macros and sources, cross-compiling for foreign architectures, linking, handling upgrades, transient dependency versioning, handling conflicts, feature gating, optional compilation, custom linting and strictness, installing sidecars and cli utilities, etc. etc.

Once it's hermetic and namespaced, cargo will be better than apt / yum / etc. They're not really performing the same tasks, but cargo is just so damned good at such important things that it's hard to imagine a better tool.

Language-specific package managers are a natural outgrowth of wanting portability across platforms.

When distros figure out how I can test my software with a dep at version A and the same dep at version B in a straightforward way, then we can talk.

NPM forcing a human to click a button on release would have solved a lot of this stuff. So would have many other mitigations.

I run them inside a sandbox.

The npm community is too big that one can never discard it for frontend development.

Javascript is a standard with many implementations. Any addition to the "standard library" (such as it is) has to go through a long process to get approved by a committee, then in turn implemented by at least the major implementations (v8, SpiderMonkey, JavascriptKit).

> Or at least first party libraries maintained by the JavaScript team?

There is no "JavaScript team".

Mainly I think because of the scale it's used at, the things it's used for, and the people who use it.

Technicalities are secondary to those factors.

If Ruby was the only language that ran in the browser, you'd be writing the same rant about Ruby, no matter the stdlib.

There has been an effort to both replace npm with a better model and to have a stable standard library. See https://jsr.io/@std