3 ms·

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

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?

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?