Re: [lfs-dev] Potential problems with the LFS and BLFS 12.3 release
| Newsgroups | gmane.linux.lfs.beyond.devel,gmane.linux.lfs.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 2025-02-27 at 10:26 +0100, Thomas Trepl wrote: > 3. Change the note to "The Linux kernel is updated quite frequently, many > times due to discoveries of security vulnerabilities. The book has been > tested on the documented kernel version of &kernel-version;. If there are > newer versions, those version might be used if there are urgent reasons, > but there is no guarantee that newer kernel version can be just dropped in > without impact on user land programs."Â (or so) The *kernel* can be just dropped in. The headers may not. Thus we can say "use the latest point release for chapter 10, but still use 6.13.2 for chapter 5." instead. But then the Glibc upgrade progress still mentions "updating the kernel API headers," and in *every* SA we tell people to "update to ..." and I'm pretty sure this problem is not limited to kernel API headers vs. systemd/udev. When the user applies *any* SA there's a chance some downstream packages will start failing to build. And I cannot see any possible resolution to the problem with just our five or seven guys in the editor team. > So we can stay on 6.13.2 and release it as is. Kernel upgrades do occur > very often and when we tell the user to always use the latest, it would > mean the user has to redo LFS every some days and our "release" is rendered > invalid. > We know that 12.3 works pretty fine on 6.13.2. Thats good and it is a > pretty good starting point for a user looking for a stable system. We assume users are using the latest point release of the kernel so we don't need to issue SA for kernel vulnerabilities. If the assumption is broken our "security response" would be pointless. Perhaps it's the time to admit "well we just tell you how to build a system, keeping it secure is your own business" and stop spending our time on security response to use our efforts on something more useful, or maybe just sleep a little longer. -- Xi Ruoyao <[email protected]> School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/sympa/info/blfs-dev Unsubscribe: See the above information page