← Back to context

Comment by m4rtink

2 days ago

Can 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 ?

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.

  • > Look at all the exploits with things like libxz

    You mean 1 in history vs several every week? Looks to me that there actually is a difference.

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?

  • >workflow that shipped the libxz backdoor to everyone

    Isn't it the case that it didn't ship the backdoor? Precisely because of the thorough testing and vetting process?

    • No, it shipped in Debian Sid, OpenSUSE Tumbleweed and Fedora Rawhide, along with beta versions of Ubuntu 24.04 and Fedora 40. Arch also shipped it but the code looked for rpm/apt distros so the payload didn’t trigger.

      It was caught by a Postgres developer who noticed strange performance on their Debian Sid system, not by anyone involved with the distro packaging process.

      3 replies →

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.

  • It's got all the same issues as npm though. The fact that it's so cool makes it a magnet for adding deps. Rust's own docs generator pulls in > 700 deps