Re: [lfs-dev] Potential problems with the LFS and BLFS 12.3 release

"Xi Ruoyao" ([email protected] via blfs-dev Mailing List) <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.