Comment by c7b
10 hours ago
I don't have an answer what the alternative is going to look like. But smarter people than me may find something. C/C++ are doing fine without package managers. Go at least has a more capable standard library than Rust. But I'm not sure if Go's import github approach is the answer.
One idea I've been entertaining is to not allow transitive imports in packages. It would probably lead to far fewer and more capable packages, and a bigger standard library. Much harder to imagine a left-pad incident in such an ecosystem.
> Go at least has a more capable standard library than Rust.
Many Golang projects I see in the wild will import a number of dependencies with significant feature overlap with sections of the standard library, or even be intended as a replacement for them. So it seems that having an expansive stdlib isn’t sufficient to avoid deep dependency trees, it probably helps to some degree but it’s definitely not a panacea.
That's not really that surprising when you think about it. Standard library-provided things are implemented on a basis of working OK for as many scenarios as possible, not on one of being the best possible implementation for every possible scenario.
The solution exists, and those are curated package repositories as we have in Linux distributions. In C I can simply install a -dev package and use some library which sees some quality control and security updates from the distribution.
The problem is that the UNIX shell model got very successful and is now also used on other platforms with poor package management, so all the language-level packaging system were created instead. But those did not learn from the lessons of Linux distributions. Cargo is particularly bad.
TFA is literally talking about vulnerabilities in Linux packages. There are gajillions of them. Curated package repositories are not solving this problem.
It talks about "installing software". You should definitely install updates from your Linux distribution and installing new packages from a curated repository is certainly not worse than having software already installed. Reducing the footprint is always a good idea though. Installing software from random uncurated sources is generally risky.
I think curated package repositories solve a problem, but not all of them.
For example, I'm not sure if the world of windows freeware ever moved past this, but very often, the home page for a freeware package will look nearly identical to a page set up to deliver malware. Every package you download you wonder "is this the legit version?". Even push it further, there were multiple examples of sites that were previously trusted for software downloads(SourceForge and the installer debacle) that began packaging spyware or adware into downloads.
With either delivery method, you're not quite safe from supply chain attacks, but with the curated repo, you at least have a single source of packages where you can trust it 99% of the time.
>C/C++ are doing fine without package managers.
They're not either, every one of these projects contains a gigantic vendor/ folder full of unmaintained libraries, modified so much that keeping up with the latest changes is impossible so they're stuck with whatever version they copied back in 2009.
You make that sound worse than it is. On the overall topic, you have 0 supply chain risk, and the whole thing is local. Also, your code from 2009 is still valid. That would be a foreign concept in some languages like Python.
you have your supply chain risk still, it's just frozen as of 2009 and whatever you vendored back then is as of today swiss cheese; also you'd better have the compiler suite vendored, too (as you should with this strategy).
there's nothing stopping you from using python from 2009 except why would you want to do that to yourself - but the same strategy applies. the reference python implementation is written in C, after all.
In C and C++'s case, the batteries included is POSIX + Khronos.