Package managers are providing (in the most case) a free service, so it's hard to see a strong case for them providing more services here.

The problem is one of scale. npm has over 500,000 packages, so no manual review will address their scale over the whole repository.

Until the developer market shows that they'll pay for a more secure service (e.g. package signed, reviews done etc) I doubt much will change.

It always worries me when I install a well-known or large package from npm and it ends up downloading dozens of dependencies maintained by disparate and unaccountable github users.

Maybe most of those 500,000 packages simply shouldn't be trusted.

There's a precedent for curated subsets of package ecosystems. Stackage for Haskell is an example, although it doesn't have security as the primary goal.

I don't think we should focus on actual audits of packages. Just checking that packages seem basically credible seems like a better approach because it's doable.

Credibility is an easier check but still tricky. Many of the package are uploaded by anonymous or pseudonymous authors, so there's no easy way to even tie that to an IRL identity, let alone check for credibility.

I'd agree that a curated small package repository would be a better way to address the problem, but the market doesn't seem very interested in that as a solution.

I think it might just not have happened yet. The npm community can be pretty creative and enthusiastic!

I don't think IRL identities are necessary for what I imagine. It's more like establishing a basic set of packages that have been around, have communities of committers, reverse dependencies, etc.

Maybe we would even make a starting assumption that the transitive closure of dependencies originating with a set of high profile packages are "approved".

I'm thinking aloud but I think there could be a reasonably pragmatic way to get this started...

So, apologies for being a bit cynical here, but I don't see this one being addressed any time soon.

it's been at least 5 years since npm started getting scrutiny relating to security weaknesses https://blog.andyet.com/2012/03/08/compromising-the-integrit...

and 4 years since Rubygems was compromised http://blog.rubygems.org/2013/01/31/data-verification.html

and yet, I don't see substantial movements relating to package security and trustability in these repo's. To be clear I'm not suggesting these two are any worse than others, they're just large repo's who have had incidents in the past.

The problem here (to my view) is that increasing the security of package repo's will slow down releases (additional checks take time) and cost money (additional security, hosting etc) and until there's a market demand for those service, they won't happen.

I'm skeptical too. But if I think like a sci-fi writer I can vaguely imagine ways for it to actually happen. That open source maintenance happens at all is pretty remarkable, so I think this thing, with an appropriate concept and some good tools (with emojis in their command line output), is at least vaguely plausible...

I don't see any reason it can't be done, either, in theory, and that's with the manual approach. Fancier ideas are viable too, but 500k is still relatively tiny and a manually tractable number. Incremental reviews starting today by many coordinating groups in the node community would take a while to complete, maybe a few years, but with some sensible ordering heuristics like e.g. the most downloaded first, or the most suspicious names first, some value could be produced quickly. But it won't happen, package vetting isn't really a value in these communities. (And that might not really be a bad thing, at least for now...)

If there was a business/enterprise offering with extra security I'm sure they'd have a long list of people who would sign up and happily pay for it.

Those service already exit, e.g. https://www.sourceclear.com/ whilst I hope they're doing well, I don't think they've made significant in-roads into the volume of people using open source software library repo's.

It needs to be part of PyPi directly, I would have a difficult time trusting and unknown third-party.

The conda package manager is free and generally feels like a professional package manager like yum or apt-get.

Yes, Conda [0] is a package manager designed by Continuum Analytics (now Anaconda, Inc.) to support their Anaconda Distribution [1]. The distribution is free, and the Conda client is open source. However, Anaconda sells several enterprise products, including an on-premise Conda server ("Anaconda Repository").

In general, Conda does more package verification than pip, and the packages in the Anaconda distribution are more thoroughly vetted than PyPi. Conda-Forge [2] provides an escape hatch for less-vetted community code.

[0] https://conda.io/docs/index.html [1] https://www.anaconda.com/distribution/ [2] https://conda-forge.org/

Five hundred thousand packages, am I reading it right? I dont believe top ten OS package managers combined would reach that number. Either this is a typo or it's crazy.

Not a typo, http://www.modulecounts.com/ has the details. npm is adding 497/day at the moment.

This [1] is npm growth compared to anything else. God this can't be safe nor sane...

[1] https://imgur.com/a/enjvR

The left-pad disaster has been predicted well in advance...

There's nothing especially awful about left-pad being its own package, the disaster was because a huge number of developers were betting on npm to somehow be highly available (despite being donated by its admins at no cost and with no committed SLA) rather than vendoring their deps.

Vendoring thousands of tiny libs is even worse. Trusting many lesser known, tiny libs is more risky than few, big well known ones.

Also, they are not vetted and there are much more opportunities for an attacker to sneak in a backdoored lib on the edge of the dependency graph.

Finally, due to vendoring there's no way to receive timely drop-in security fixes for all dependencies from a trusted source.

One can both vendor and use the package manager to fetch updates. Just add the node-modules directory to your VCS.

The thing with node is that AFAIK it requires you to have libraries for what in most languages would be in the standard library. Maybe someone should start a "stdnode" project where the most popular / successful libraries for generic tasks are integrated into a dependable, maintained de-facto standard library, with an eye on quality and sanity, and community / Joyent funding.

JS is the most popular language on GitHub by far, and npm is a public site where anyone can instantly upload as many new packages as they want...

JS devs usually make packages that have single functions....