> He's arguing for developers to be more conscious of the dependencies they use

"be careful all the time" doesn't scale. Half of all developers have below-average diligence, and that's a low bar. No-one is always vigilant, don't think that you're immune to human error.

No, you need tooling, automation to assist. It needs to be supported at the package manager side. Managing a site where many files are uploaded, and then downloaded many times is not a trivial undertaking. It comes with oversight responsibilities. If it's video you have to check for CSAM. If it's executable code, then you have to check for malware.

Package managers are not evil, but they are a tempting target and need to be secured. This can't just be an individual consumer responsibility.

I can't speak for other ecosystems, but some NuGet measures are here:

https://devblogs.microsoft.com/dotnet/building-a-safer-futur...

https://learn.microsoft.com/en-us/nuget/concepts/security-be...

I believe that there have been (a few) successful compromises of packages in NuGet, and that these have been mitigated. I don't know how intense the arms race is now.

▲

pjc50 4 days ago | parent | next [-]

> "be careful all the time" doesn't scale

Yes, this is the C attitude, where you provide no safety rails or poka-yokes or, indeed, package managers, and therefore you get a lot of fragile reimplementations of package managers (autoconf, anyone?). But you get to keep the satisfaction of blaming the users.

nuget is pretty good. It helps that packages tend to be substantial things, not left-pad.

	▲	1718627440 4 days ago \| parent \| next [-]
		> autoconf, anyone? GNU Autoconf isn't a package manager, it's more an analogue to a setup executable on MS Windows, to detect where the user wants stuff to be installed, where the user has stuff already installed and which features the user wants.
	▲	SideburnsOfDoom 4 days ago \| parent \| prev [-]
		> It helps that packages tend to be substantial things, not left-pad. Agree, this is IMHO also a better pattern. 1-liners or even 20-liners are not worth the overhead of extracting a package. Or of depending on a package.

▲

cayleyh 4 days ago | parent | prev | next [-]

"Half of all developers have below-average diligence" - a lot of this is also not developer choice, but environmental. So much software is developed and maintained in very constrained economic environments, often by solo devs who also have other responsibilities. The choice here often is trading some "diligence" for "meeting business requirements in the time / budget constraints" imposed by your employer.

	▲	SideburnsOfDoom 4 days ago \| parent [-]
		Absolutely true, but still indicates the need for tooling, for automation, and for oversight at the the package store. "developers, be more conscious" isn't going to fix all the issues. In general, there are not individual effort fixes to systemic issues.

▲

ozim 3 days ago | parent | prev [-]

That's not package manager problem that's registry problem. NuGet is not having as many problems as NPM but also NPM is much more popular.

NPM is also quite a wild west when it comes to publishing packages, any kid can make an account and publish 'left-pad' kind of crap.

We already have quite safe and working setup with APT and software repositories for Debian, Ubuntu etc. While it is not so easy to publish your software to Debian, you get dedicated maintainer and all kinds of requirements you have to fulfill.

But this way all the issues with trust are if not mitigated, they are minimized and for example XZ Utils hack didn't make it to production systems and it took 3 years to prepare and pull it off.

▲

SideburnsOfDoom 3 days ago | parent [-]

> That's not package manager problem that's registry problem

I do not think that the two are cleanly separable. They are client and server ends of the same system.

And I think my point is that I view it as more of a server (registry) and governance problem than the OP author does.

Despite the fact that my employer also has an internal package feed, the security of nuget.org and the central public feed is intrinsic to the security of the whole system.

Nuget was closer to the NPM end of the spectrum, but has tightened up considerably over time. Particularly the "Package ID Prefix Reservations" feature tells me that package names that start with certain words are owned by the relevant entity, be it "System." or "Azure." from Microsoft, or "AWS" from Amazon.

This is important as it's used to distribute SDKs and optional but standard library components and updates.

There is certainly junk on there, but not much load-bearing junk.

▲

ozim 3 days ago | parent [-]

Article is discussing „package manager” as generic concept.

My argument was that this concept is not the problem.

Problem is in governance of NPM while NuGet or Maven are stricter and therefore it is registry governance problem.

But on the other hand NPM is much more popular than any other registry.

▲

SideburnsOfDoom 3 days ago | parent [-]

> Article is discussing „package manager” as generic concept. My argument was that this concept is not the problem. Problem is in governance of NPM

Then we're in agreement that the article's author has the wrong end of the stick, by focusing on the client end of the file transfer connection.

	▲	gingerBill 3 days ago \| parent [-]
		Huh? I am not saying the repositories have (or should have) no responsibility, but you are also responsible for your own actions. The popularity of such repositories and package managers are due to users of them. And the concepts are trivially separable in my opinion. A package manager uses a repo of packages to download from. You don't need a package manager to use a repo. And a package manager could be just local to your machine and thus not need an external repo either. I know in practice the two are combined but that doesn't mean they are not distinct concepts.