[nailer]

I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong.

So, explicitly:

- pip

- Cargo

- apt/dpkg

- dnf/yum

- Homebrew

- RubyGems

- Composer (limited)

- Maven

...all allow scripts.

We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager.

npm shouldn't allow scripts, but exploits happen everywhere.

[m4rtink]

If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution.

Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack.

Definitely not bulletproof but still IMHO more robust than "Lets just spray latest code from upstream without any review directly to production with a firehose!" that seems to be the norm.

[isityettime]

Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it. But there are norms in the distro about what those scripts are for and how to use them, and there's some social enforcement around that.

The real issue for hooks in packaging formats like those is when you start adding third-party vendor repositories, e.g., Zoom, Google Chrome, Discord. None of the social enforcement mechanisms are there and the companies behind the products I just mentioned all have histories of abusing them.

That's why it's generally better to use Flatpak for things like that if your distro itself doesn't include them.

[nailer]

> Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it.

Not all packages come from the distro. People can and do enable external sources for software that isn't part of their OS.

[isityettime]

Read the third sentence in the comment you're ostensibly replying to, friend.

[tetha]

Also the APT and RPM world lets packages sit for a long time - those are called "testing" and "unstable" in the Debian world. It's slow, but it seems hard to move intentional exploits with short-term payoffs through as far as we can see.

That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.

[cozzyd]

Yes and typically updates take a while to be deployed...

[krautsauer]

Are scripts even necessary? I don't think e.g. mvn has any form of scripts¹, but if the dependency is compromised, you're likely to execute whatever compromised code is in there the next time you do mvn verify (or whatever). Slightly less wormable maybe, running tests or at least checking whether your thing still runs after upgrading package versions is really common, no?

¹ Annotation processors are a thing and somewhat similar to rust macros in function, but you need to set those up manually for each dependency, iirc.

[Zardoz84]

ant-plugin and maven-assembly.

But pulling a maven dependency DON'T run anything. You must download the repository that contains the POM.XML and run mvn with any goal that triggers the lifecycle.

Maven 4 aims to separate distribution and build poms. Currently, we generate distribution pom.xml for distribution using flatten plugin.

[xienze]

Maven does not run arbitrary scripts just by including a dependency.

[wang_li]

It's not the package manager, it's the repo and the cryptographic signatures that are trusted by the package manager and the users who choose to point their pacakge managers at those repos. The fundamental problem here is that people's risk assessment is treating a user named devioustiger12345 as having the same situation and story as Microsoft/Apple/Red Hat.

[bananamogul]

You didn't include Perl's CPAN, which I think is older (1995) than all of these. And it allows scripts as well.

[matheusmoreira]

> HN downmodded the first comment to hell but I know I'm right and the crowd is wrong.

Got downvoted for saying it too. Don't let it discourage you.