[Panzerschrek]

I didn't say one should not use thirdparty dependencies at all. They are sometimes useful. But they should be chosen carefully and ideally reviewed. And any updates should be done manually in order to prevent security chain attacks.

Having a standardized package manager allows lowering the bar and bypassing careful thinking. It has also a cumulative effect - if one adds each dependency in its project one by one with proper audits, transitive dependencies may not be managed so carefully. And then we have cargo-style cancer with trivial projects having hundreds of dependent packages.

[rcxdude]

The C++ style tends to create much larger omnibus libraries. If you're concerned about the liability and bloat extra dependencies create, you should be thinking of a) the number of people you are trusting in your supply chain, and b) the total amount of code you are importing. Neither of these correlate directly with the number of different packages that appear in your package manager, and in fact cargo-style splitting can allow you much more fine-grained control over what code appears in your application.

Probably the one security sin of most language package managers is allowing anyone to upload to the central repository without review. This is good for accessibility but bad for security. There are tools like cargo-crev, though, which can help you enforce some level of vetting if you wish.

[simonask]

I don't think masochism is a reliable or sound security strategy.

[uecker]

On the other hand, systems like cargo a clearly a supply chain disaster.

I also think that languages should not have their own specific packaging system. This should be done on a distribution level, which provides curated lists of software. This system works well in the Linux world. The problem is the support for the commercial platforms.

The whole trend to think of programming languages as closed frameworks is bad. It is replacing a better system with one which is fundamentally much worse, instead of trying to fix the problems with the existing systems (which is hard because it needs collaboration and harmonization, instead of going into your own little bubble and pretending to do something superior).

[simonask]

> On the other hand, systems like cargo a clearly a supply chain disaster.

I don't think that has been shown to be true. There's a lot of FUD, though. Tools like `cargo vet` and `cargo audit` seem to be pretty good.

> I also think that languages should not have their own specific packaging system. This should be done on a distribution level, which provides curated lists of software. This system works well in the Linux world. The problem is the support for the commercial platforms.

I mean, it works until it doesn't. There are really significant drawbacks to this as well, including the knack some distributors have for thinking they know better than the original developer.

[uecker]

I think there were enough attacks already for cargo that one can not call this FUD. It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model.

The Linux distribution model worked perfectly fine for the 30 years I am using Linux.

[simonask]

> I think there were enough attacks already for cargo that one can not call this FUD.

What attacks are you referring to specifically?

> It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model.

This is the FUD I'm talking about. If you worry about supply chain attacks, it's not harder to be careful just because dealing with dependencies in general is much easier. You have to vet your dependencies no matter what.

> The Linux distribution model worked perfectly fine for the 30 years I am using Linux.

The xz scandal was a damn close call. Linux is a forest of distributions, and each distribution is a separate vulnerable organization.

[uecker]

I do not keep track of them, but google finds CrateDepression, faster_log, async_println, finch-rust or recently: https://cybersecuritynews.com/supply-chain-trapdoor-malware/

It is not FUD as it is a real risk. cargo audit can only search for known issues, as such is like a virus scanner, often being too late. "You have to vet your dependencies no matter what" sounds nice, but Rust packages tend to pull in many hundreds of dependencies. But even for the comparable fewer dependencies in other languages, you can not usually vet everything yourself, you need to rely on the community to help. But then you need to have a curated software distribution, and this is exactly what traditional Linux distribution model does, while cargo does not.

xz scandal was a close call, but it was also a very sophisticated operation - which was then discovered by a Debian developer. This is not at all comparable to the cheap type squatting style attacks possible with cargo and confirms my point.