alt Hacker NewsCan we finally decare this (and other incomplete language specific package namanegers) to be a failed experiment and go back to robust and secure distro based package management workflow, with maintainers separate from upstream developpers ?
Replies
The robust and secure distro based package management workflow that shipped the libxz backdoor to everyone, and broke openssh key generation, and most of the functionality of keepassxc?
where do you get all these trusted people to review your dependencies from?
it can't be anyone, because you're essentially delegating trust.
no way there's enough trustworthy volunteers (and how do you vet them all?)
and who's going to pay them if they're not volunteers?
Language-specific package managers are a natural outgrowth of wanting portability across platforms.
When distros figure out how I can test my software with a dep at version A and the same dep at version B in a straightforward way, then we can talk.
NPM forcing a human to click a button on release would have solved a lot of this stuff. So would have many other mitigations.
I run them inside a sandbox.
The npm community is too big that one can never discard it for frontend development.
Never in a million years.
Rust's Cargo is sublime. System apt / yum / pacman / brew could never replace it.
Cargo handles so much responsibility outside of system packages that they couldn't even come close to replicating the utility.
Checking language versions, editions, compiling macros and sources, cross-compiling for foreign architectures, linking, handling upgrades, transient dependency versioning, handling conflicts, feature gating, optional compilation, custom linting and strictness, installing sidecars and cli utilities, etc. etc.
Once it's hermetic and namespaced, cargo will be better than apt / yum / etc. They're not really performing the same tasks, but cargo is just so damned good at such important things that it's hard to imagine a better tool.
Its a false belief that distro based package management workflows are, or ever were, more secure. Its the same problem, maybe one step removed. Look at all the exploits with things like libxz
There was also the python 2.7 problem for a long time, thanks to this model, it couldn't be updated quickly and developers, including the OS developers, became dependent on it being there by default, and built things around it.
Then when it EOL'd, it left alot of people exposed to vulnerabilities and was quite the mess to update.