Re: Potential problems with the LFS and BLFS 12.3 release

On Wed, 2025-02-26 at 13:19 -0600, Bruce Dubbs wrote:
> We have a potential problem with LFS and BLFS that I am asking for feedback on how to 
> proceed.
> 
> CURRENT
>    We have LFS and BLFS almost ready to go with a few packages (3) that still need 
> testing on specialized hardware. There are also a few tweaks needed to some 
> instructions, but there are no show stoppers.
> 
> PROBLEM
>    I was testing some LFS packages that have come in during the package freeze and 
> ran into a problem with udev/systemd. This problem is caused by a change in the 
> kernel headers for linux-6.13.4 that cause udev/systemd to fail. This problem can be 
> fixed with two seds or by upgrading to systemd-257.3 but we cannot be sure that the
> rest of the many applications and libraries that depend on systemd/udev will work
> properly unless we go through extensive testing. The changes are not needed for
> what we have now using the linux-6.13.2 kernel.
> 
>   The problem now occurs if a user upgrades the kernel when building LFS.  We say:
> "The Linux kernel is updated quite frequently, many times due to discoveries of 
> security vulnerabilities. The latest available stable kernel version may be used, 
> unless the errata page says otherwise."
> 
> Here are our options:
> 
> 1. Continue with the 12.3 release.  We can add to the errata to tell users NOT to
>     use the latest kernel or we can remove that quote above.
> 
> 2. We can release a new lfs-12.3-rc2 and restart the testing process. This
>     will delay the release schedule by one to two weeks but will make upgrades
>     easier for users. It will also allow us to incorporate newer package versions
>     that have published security issues.
> 
>     I'll note here that there is no guarantee that during the delay that new
>     packages with security issues will not be released. Sometimes a new package
>     is not an issue, but the current problem is that udev/systemd touches a huge
>     number of packages and we don't have a good way to ensure everything is
>     consistent without re-testing everything.

I'd propose "the option 3": update but keep API and ABI frozen.

For the kernel, we should tell the users only update the kernel (i.e.
chapter 10) to the latest minor version, not the API headers (i.e.
chapter 5).

For the vulnerable packages (assuming they don't provide a static
library), apply patches to them w/o touching their installed headers
(API) or the shared library exported symbols (ABI).

Thus we don't need a full rebuild for testing (because as API and ABI
are frozen, our changes cannot cause a build failure).  We just need to
run the programs and see if they function as expected.

If 3 seems too cumbersome to the team I'd vote for 2.  1 is not
acceptable to me.  We've already stopped announcing kernel
vulnerabilities in our SA assuming the users will use the latest point
release.  If the assumption is broken we'll have to either announce so
many SA, or stop to issue SA at all and admit we cannot do that.


-- 
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