[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.