On 08/15/2018 09:52 PM, Douglas R. Reno wrote:
On Wed, Aug 15, 2018 at 9:44 PM DJ Lucas <[email protected]
<mailto:[email protected]>> wrote:
Discussion was requested in bug to see if security issues should be
fixed before or after release. There are two low severity security
issues in OpenSSL-1.1.0h currently in rc1. My thoughts, there is a low
probability of breakage, and since we need to do kernel and headers
again (again, I assumed this was a necessity instead of discussion), I
figured OpenSSL would be a shoe-in as a result of that. I don't see a
problem with it, but understand that there is some risk of breakage.
The
same is true of all the updates, but again, all minimal risk.
I figure at least a few of us haven't updated to the RC yet, so any
issues would be discovered on those rebuilds (these would only be
packages between end of LFS and Xorg in BLFS). If nobody else is
planning on full rebuild for RC, I can commit to rebuilding everything
that depends on them currently to validate after I complete the few
items I've assigned to myself.
I've updated all outstanding packages that I've slotted for 8.3,
including the obligatory glibc rebuild for new kernel headers, and am
proceeding with those changes in place. Unfortunately, the updates did
not come in until after I had completed Xorg (2nd milestone on my build
order). I intend to do a short overnight build of LFS in a different
prefix.
Thoughts? I guess really, do any editors intend to start from scratch
for the RC period or is everyone up to date already?
--DJ
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
I'm going to have to start from scratch here at the end of the week to
do validation properly. I think all editors should be running an
official build of the -rc (e.g. not updated), but I'm not 100% sure.
The kernel update contains the L1TF mitigation, which is critical for
anyone who uses qemu or any other virtualization software on an Intel
processor. That in itself is bad enough IMO.
We also need to consider the backlash possible if we do not update to
the latest OpenSSL version prior to release.
In addition, the version of iproute2 in the book currently is designed
to be running against 4.17 headers, not 4.18 headers. As a result, some
features will not be built.
I think a new -rc based off the updates needs to be performed. The
kernel level vulnerability is HIGH (last I checked), and not LOW.
We need to discuss the OpenSSH User Account Disclosure vulnerability
that was just found and shipped straight to oss-security instead of
going through oss-distros first as well, as that was slotted for
immediate disclosure instead of an embargo as is standard [1] - we
cannot release without that fix, unless we plan on making an errata and
an announcement immediately after. This affects every version of OpenSSH
from 2.2+ and can be used to enumerate usernames.
[1] - http://seclists.org/oss-sec/2018/q3/124
My problem is how do we get a release out when these things are popping
up every few days. We need a couple of weeks to validate all the
packages. I've been updating packages and tagging those that don't need
updating for a couple of days now. I have 74 in my log so far.
Today is the 15th. I can start over with the new packages, but it will
probably take a full day to get back to where I am now. What happens
when someone pushes a change on the 20th? On the 25th? Do we continue
to start over? Do we just make the changes in place and continue?
We already tell users "The latest available 4.18.x kernel version should
be used" I suspect the other packages: openssl, iproute2, and even
expect will not really affect our validation process, but a kernel
change affects Section 6.7. Linux-4.18 API Headers and that has the
potential to affect a lot of things.
I'll bet any editor a lunch that by the time we get to the scheduled
release date (September 1) the kernel will be at at least 4.18.5.
I do not know the best way to proceed, but I am very concerned about the
upstream churn and our ability to produce a stable LFS/BLFS release.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
