4 ms·

This is why we should use packages from well-known Linux distributions instead of npm/pip/cargo etc. I know the available libraries are a fraction of the ecosy

This is why we should use packages from well-known Linux distributions instead of npm/pip/cargo etc. I know the available libraries are a fraction of the ecosystem, but very often it's a good enough fraction if you are willing to be flexible in your choices.

maxloh 4y ago
You cannot download React from apt/yum AFAIK.
- goodpoint 4y ago
  https://packages.debian.org/source/bullseye/i386/node-react https://packages.debian.org/source/bullseye/i386/node-react This one? EDIT: it's a bit old, probably due to the usual mess of dependency management in JS. Still perfectly usable tho. Having seen that, I would stay away from react.
  - Gigachad 4y ago
    That package is wildly out of date. I’d estimate the vast majority of react apps are running on a much newer version. And no one wants to have their react upgrade tied to a Debian upgrade. Forcing these things to happen at the same time would be a nightmare.
noodlesUK 4y ago
Serious question: what’s the difference? Do Linux distros actually audit packages very much? Supply chain attacks in Linux distros are pretty scary, as you can basically expect them to run install scripts as root.
- goodpoint 4y ago
  > Do Linux distros actually audit packages very much? It varies widely depending on the distro. Debian is the the most strict on review process but also on screening the volunteers doing the work. Yet, most popular distros has been very effective at blocking a large number of supply chain attacks over the last 20 years.
- Gigachad 4y ago
  A bit, but I assume it’s mostly just the extra friction to get things in that acts as the main filter. Malware has made it in to Debian before. See the xscreensaver time bomb. The extra friction also makes Linux package managers useless. Just about 0% of the things people are installing with npm exist in distro repos. Distro repos are also extremely poor at keeping multiple versions around at once. Surprisingly people don’t like having their react upgrade tied to the Debian major version update.
pmontra 4y ago
A fraction and based on my old Ruby gems memories, fairly out of date. I remember that somebody posted a reply to a comment of mine here on HN years ago saying that s/he was rebuilding every single gem as deb package before deploying it in production and that was the only sensible way to do. I don't think it adds much to security unless they also read all the code, but it's a lot of work that none of my customer is going to pay me for. I also probably don't want to start a profession of deb builder for Ruby gems.
- logifail 4y ago
  > A fraction and based on my old Ruby gems memories, fairly out of date That's almost certainly true, but the case of having to choose, I'd almost always select slightly older but trusted code to less trustworthy bleeding-edge-newness. I guess that's why I'm content with dozens of instances running Debian.
  - pcl 4y ago
    Older dependencies, of course, might contain security vulnerabilities that have been patched in more recent version updates. Its a frustrating choice: stay on old versions and risk exposure to old vulns, or stay up-to-date and risk supply chain attacks.
    - goodpoint 4y ago
      No, it's the very opposite. Vulnerabilities can be discovered in released software, but new vulnerabilities are only introduced in new releases. Security fixes are backported by the distro. Over time, stable distributions become and remain more secure than cutting edge software.
- goodpoint 4y ago
  Various large organizations rebuild Debian to detect unexpected changes both as part of https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds and independently. > I don't think it adds much to security unless they also read all the code Some distros ensure that hundreds of thousands of users deploy and use the same packages consistently before making a distro release. This creates plenty of accountability, making it very difficult for a supply chain attack to go undetected. > A fraction and based on my old Ruby gems memories, fairly out of date. Just like buying a car, you have a tradeoff between well-known and little-known, well tested or bleeding edge. What's safer for production use?

maxloh 4y ago

You cannot download React from apt/yum AFAIK.

goodpoint 4y ago
https://packages.debian.org/source/bullseye/i386/node-react https://packages.debian.org/source/bullseye/i386/node-react This one? EDIT: it's a bit old, probably due to the usual mess of dependency management in JS. Still perfectly usable tho. Having seen that, I would stay away from react.
- Gigachad 4y ago
  That package is wildly out of date. I’d estimate the vast majority of react apps are running on a much newer version. And no one wants to have their react upgrade tied to a Debian upgrade. Forcing these things to happen at the same time would be a nightmare.

noodlesUK 4y ago

Serious question: what’s the difference? Do Linux distros actually audit packages very much? Supply chain attacks in Linux distros are pretty scary, as you can basically expect them to run install scripts as root.

goodpoint 4y ago
> Do Linux distros actually audit packages very much? It varies widely depending on the distro. Debian is the the most strict on review process but also on screening the volunteers doing the work. Yet, most popular distros has been very effective at blocking a large number of supply chain attacks over the last 20 years.
Gigachad 4y ago
A bit, but I assume it’s mostly just the extra friction to get things in that acts as the main filter. Malware has made it in to Debian before. See the xscreensaver time bomb. The extra friction also makes Linux package managers useless. Just about 0% of the things people are installing with npm exist in distro repos. Distro repos are also extremely poor at keeping multiple versions around at once. Surprisingly people don’t like having their react upgrade tied to the Debian major version update.

pmontra 4y ago

A fraction and based on my old Ruby gems memories, fairly out of date. I remember that somebody posted a reply to a comment of mine here on HN years ago saying that s/he was rebuilding every single gem as deb package before deploying it in production and that was the only sensible way to do. I don't think it adds much to security unless they also read all the code, but it's a lot of work that none of my customer is going to pay me for. I also probably don't want to start a profession of deb builder for Ruby gems.

logifail 4y ago
> A fraction and based on my old Ruby gems memories, fairly out of date That's almost certainly true, but the case of having to choose, I'd almost always select slightly older but trusted code to less trustworthy bleeding-edge-newness. I guess that's why I'm content with dozens of instances running Debian.
- pcl 4y ago
  Older dependencies, of course, might contain security vulnerabilities that have been patched in more recent version updates. Its a frustrating choice: stay on old versions and risk exposure to old vulns, or stay up-to-date and risk supply chain attacks.
  - goodpoint 4y ago
    No, it's the very opposite. Vulnerabilities can be discovered in released software, but new vulnerabilities are only introduced in new releases. Security fixes are backported by the distro. Over time, stable distributions become and remain more secure than cutting edge software.
goodpoint 4y ago
Various large organizations rebuild Debian to detect unexpected changes both as part of https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds and independently. > I don't think it adds much to security unless they also read all the code Some distros ensure that hundreds of thousands of users deploy and use the same packages consistently before making a distro release. This creates plenty of accountability, making it very difficult for a supply chain attack to go undetected. > A fraction and based on my old Ruby gems memories, fairly out of date. Just like buying a car, you have a tradeoff between well-known and little-known, well tested or bleeding edge. What's safer for production use?