4 ms·

It's a not so well guarded secret that the claims by many linux distributions that they support old systems with security fixes for many years are not really tr

by hannob 4y ago

It's a not so well guarded secret that the claims by many linux distributions that they support old systems with security fixes for many years are not really true. The number of security flaws constantly found and fixed is just too large to make this even remotely feasibile. This is just another instance of this.

xxpor 4y ago
OTOH, a lot of customers probably aren't too worried about low severity, local attack vector bugs.
77AA777 4y ago
Can confirm this is a very real problem with a long history. Quoting from a sort of Arch-specific security hardening page[1]: > A common misconception about the Linux kernel is that it's secure, or that users can go a long time without worrying about security updates. Neither of these are even remotely true. New versions of Linux are released almost every week, often containing important security fixes among the other changes. These releases typically don't make explicit mention of which commits have security implications. As a result, many "stable" or "LTS" distributions don't know which commits should be backported to their old kernels, or even that something needs backporting at all. If the problem has a CVE assigned to it, maybe your distribution will pick it up. Maybe not. Even if a CVE exists, at least in the case of Ubuntu and Debian especially, users are often left with kernels full of known holes for months at a time. Red Hat and similar "enterprise" distros have the same problem and have been called out publicly about it on more than one occasion. Moreover, the Linux kernel security team doesn't request CVEs for any vulnerabilities, partly because there are just too many to track. Downstream's culture of trying to cherrypick security fixes in the name of stability does not work. Arch doesn't play the backporting game, instead opting to provide the newest stable kernels shortly after their upstream release. [1]: https://vez.mrsk.me/linux-hardening.html https://vez.mrsk.me/linux-hardening.html (lots of linked sources in the actual paragraph there)
- deafpolygon 4y ago
  This is one reason why I don't mainline a Linux desktop anymore. It's just too much sysadmin work to stay on top of it, in addition to all of the desktop issues. When even the creator of the Linux kernel has a very lax approach to security, and so the culture of Linux is the same way - I consider it an issue.
  - aaomidi 4y ago
    Is there any real reason you don’t auto update everything, especially the kernel as a desktop user? This is one of the nice things about arch I guess. Super simple to run mainline.
    - deafpolygon 4y ago
      Experience has taught me not to be the first to beta-test a new package update, and don't blindly update. I used to run Arch and have run into scenarios multiple times where I've been unable to boot into a desktop environment because of an update. They were recoverable issues, but still cost me time and motivation for that day. That, and updates are just a constant stream - there is always a new package to update every single day. And as a separate issue, but the quality of software has taken a sharp decline lately as we all start switching to flatpaks and snaps (a correlation, not causative). More and more software is Electron-based and the quality of the non-Electron based software has more or less tanked. Not many hobby programmers are making desktop software anymore.
      - est31 4y ago
        You could try using Nix OS stable with "boot.kernelPackages = pkgs.linuxPackages_latest;". That way, you will get the latest kernel version and if there is an issue with you being unable to boot into a desktop environment, you can very easily roll back the update by rebooting and selecting an older generation in the boot manager's menu.
      - _0w8t 4y ago
        I second that. On few occasions kernel update in Fedora on my Dell XPS from 2016 cannot boot. The last time it was an upstream regression that was not fixed for months. In the mean time a bad WiFi bug was discovered. I could in theory compiled my own kernel with a fix but without the boot regression, but I rather decided to use Debian. At least they do backport fixes
josefx 4y ago
Edit: I have been corrected on the support time frame. Also had the bad luck of checking the CentOS wikipedia page to validate my memories - one of the Tables makes it look as if both CentOS stream 8 and 9 are already out of support. As far as I can tell IBM officially nuked CentOS long term support in the same step it killed Red Hat compatibility with 7 being the last supported version. The replacement for CentOS seems to be Rockit Linux, which continues with tracking Red Hat packages like CentOS did in the past.
- anonymousiam 4y ago
  I always looked upon Scientific Linux as the CentOS replacement. https://scientificlinux.org/ https://scientificlinux.org/
  - scheme271 4y ago
    Scientific Linux was killed in 2019 although security releases for SL 6 and 7 will probably continue as long as Centos 6 and 7 get them. I'd go with AlmaLinux or Rocky Linux if you want to something that's a free copy of RHEL 8 or 9
    - jaboutboul 4y ago
      CERN chose to move forward with AlmaLinux: https://linux.web.cern.ch/which/ https://linux.web.cern.ch/which/
  - chronogram 4y ago
    That's mostly replaced by Alma with the CERN repository: https://linux.web.cern.ch/which/ https://linux.web.cern.ch/which/
  - red-iron-pine 4y ago
    RockyLinux is by the guy who did CentOS, and seeks to follow it's principles. Scientific Linux is no longer a thing, essentially; from wikipedia: > In April 2019, it was announced that feature development for Scientific Linux would be discontinued, but that maintenance will continue to be provided for the 6.x and 7.x releases through the end of their life cycles. Fermilab and CERN will utilize CentOS Stream[4] and AlmaLinux[5] for their deployment of 8.x release instead.

by hannob 4y ago

xxpor 4y ago

OTOH, a lot of customers probably aren't too worried about low severity, local attack vector bugs.

77AA777 4y ago

Can confirm this is a very real problem with a long history. Quoting from a sort of Arch-specific security hardening page[1]: > A common misconception about the Linux kernel is that it's secure, or that users can go a long time without worrying about security updates. Neither of these are even remotely true. New versions of Linux are released almost every week, often containing important security fixes among the other changes. These releases typically don't make explicit mention of which commits have security implications. As a result, many "stable" or "LTS" distributions don't know which commits should be backported to their old kernels, or even that something needs backporting at all. If the problem has a CVE assigned to it, maybe your distribution will pick it up. Maybe not. Even if a CVE exists, at least in the case of Ubuntu and Debian especially, users are often left with kernels full of known holes for months at a time. Red Hat and similar "enterprise" distros have the same problem and have been called out publicly about it on more than one occasion. Moreover, the Linux kernel security team doesn't request CVEs for any vulnerabilities, partly because there are just too many to track. Downstream's culture of trying to cherrypick security fixes in the name of stability does not work. Arch doesn't play the backporting game, instead opting to provide the newest stable kernels shortly after their upstream release. [1]: https://vez.mrsk.me/linux-hardening.html https://vez.mrsk.me/linux-hardening.html (lots of linked sources in the actual paragraph there)

deafpolygon 4y ago
This is one reason why I don't mainline a Linux desktop anymore. It's just too much sysadmin work to stay on top of it, in addition to all of the desktop issues. When even the creator of the Linux kernel has a very lax approach to security, and so the culture of Linux is the same way - I consider it an issue.
- aaomidi 4y ago
  Is there any real reason you don’t auto update everything, especially the kernel as a desktop user? This is one of the nice things about arch I guess. Super simple to run mainline.
  - deafpolygon 4y ago
    Experience has taught me not to be the first to beta-test a new package update, and don't blindly update. I used to run Arch and have run into scenarios multiple times where I've been unable to boot into a desktop environment because of an update. They were recoverable issues, but still cost me time and motivation for that day. That, and updates are just a constant stream - there is always a new package to update every single day. And as a separate issue, but the quality of software has taken a sharp decline lately as we all start switching to flatpaks and snaps (a correlation, not causative). More and more software is Electron-based and the quality of the non-Electron based software has more or less tanked. Not many hobby programmers are making desktop software anymore.
    - est31 4y ago
      You could try using Nix OS stable with "boot.kernelPackages = pkgs.linuxPackages_latest;". That way, you will get the latest kernel version and if there is an issue with you being unable to boot into a desktop environment, you can very easily roll back the update by rebooting and selecting an older generation in the boot manager's menu.
    - _0w8t 4y ago
      I second that. On few occasions kernel update in Fedora on my Dell XPS from 2016 cannot boot. The last time it was an upstream regression that was not fixed for months. In the mean time a bad WiFi bug was discovered. I could in theory compiled my own kernel with a fix but without the boot regression, but I rather decided to use Debian. At least they do backport fixes

josefx 4y ago

Edit: I have been corrected on the support time frame. Also had the bad luck of checking the CentOS wikipedia page to validate my memories - one of the Tables makes it look as if both CentOS stream 8 and 9 are already out of support. As far as I can tell IBM officially nuked CentOS long term support in the same step it killed Red Hat compatibility with 7 being the last supported version. The replacement for CentOS seems to be Rockit Linux, which continues with tracking Red Hat packages like CentOS did in the past.

anonymousiam 4y ago
I always looked upon Scientific Linux as the CentOS replacement. https://scientificlinux.org/ https://scientificlinux.org/
- scheme271 4y ago
  Scientific Linux was killed in 2019 although security releases for SL 6 and 7 will probably continue as long as Centos 6 and 7 get them. I'd go with AlmaLinux or Rocky Linux if you want to something that's a free copy of RHEL 8 or 9
  - jaboutboul 4y ago
    CERN chose to move forward with AlmaLinux: https://linux.web.cern.ch/which/ https://linux.web.cern.ch/which/
- chronogram 4y ago
  That's mostly replaced by Alma with the CERN repository: https://linux.web.cern.ch/which/ https://linux.web.cern.ch/which/
- red-iron-pine 4y ago
  RockyLinux is by the guy who did CentOS, and seeks to follow it's principles. Scientific Linux is no longer a thing, essentially; from wikipedia: > In April 2019, it was announced that feature development for Scientific Linux would be discontinued, but that maintenance will continue to be provided for the 6.x and 7.x releases through the end of their life cycles. Fermilab and CERN will utilize CentOS Stream[4] and AlmaLinux[5] for their deployment of 8.x release instead.