3 ms·

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 p

by m4rtink 10mo 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 ?

ashishb 10mo ago
I run them inside a sandbox. The npm community is too big that one can never discard it for frontend development.
arccy 10mo ago
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?
Macha 10mo ago
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?
- TZubiri 10mo ago
  >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?
  - Macha 10mo ago
    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.
    - gr4vityWall 10mo ago
      In other words, it didn't hit any people running Stable distros, only users on Beta versions or rolling releases. Sounds like an improvement - having beta builds for people to catch those before they arrive in a stable GNU distribution seems the ideal workflow at glance.
      - graemep 10mo ago
        On top of that the number of such issues is tiny compared to language distros. Distro packaging is not perfect, but it is much, much better.
    - TZubiri 10mo ago
      App devs are part of the distro release process. They verify stability with other packages. It's OS, it's a collab endeavour
echelon 10mo ago
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.
- socalgal2 10mo ago
  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
no_wizard 10mo ago
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.
- LtWorf 10mo ago
  > 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.
rtpg 10mo ago
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.
sunshowers 10mo ago
Language-specific package managers are a natural outgrowth of wanting portability across platforms.

by m4rtink 10mo ago

ashishb 10mo ago

I run them inside a sandbox. The npm community is too big that one can never discard it for frontend development.

arccy 10mo ago

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?

Macha 10mo ago

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?

TZubiri 10mo ago
>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?
- Macha 10mo ago
  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.
  - gr4vityWall 10mo ago
    In other words, it didn't hit any people running Stable distros, only users on Beta versions or rolling releases. Sounds like an improvement - having beta builds for people to catch those before they arrive in a stable GNU distribution seems the ideal workflow at glance.
    - graemep 10mo ago
      On top of that the number of such issues is tiny compared to language distros. Distro packaging is not perfect, but it is much, much better.
  - TZubiri 10mo ago
    App devs are part of the distro release process. They verify stability with other packages. It's OS, it's a collab endeavour

echelon 10mo ago

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.

socalgal2 10mo ago
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

no_wizard 10mo ago

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.

LtWorf 10mo ago
> 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.

rtpg 10mo ago

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.

sunshowers 10mo ago

Language-specific package managers are a natural outgrowth of wanting portability across platforms.