On 08/16/2018 09:51 AM, DJ Lucas wrote:
Got caught someplace so sending directly to those who have replied already,
think it kind of important... I've had mail problems lately.
--DJ
-------- Original Message --------
From: DJ Lucas <[email protected]>
Sent: August 16, 2018 1:11:09 AM CDT
To: LFS Developers Mailinglist <[email protected]>
Subject: Re: [lfs-dev] RC1 security issues
On August 15, 2018 10:36:58 PM CDT, Bruce Dubbs <[email protected]>
wrote:
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?
I'd suggest making the changes in place. For right now, that's install
new kennel headers (can just install over existing, I've already
confirmed all are overwritten), then rebuild glibc, update iproute2,
openssl, and kernel.
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.
I don't disagree with anything above, but bigger security issues such as
l1tf simply can't appear in a release if the announcement was made
before release date. It doesn't matter that it also say "use latest
patch version," DW will see 4.18.0. This would create a terrible
perception of LFS release quality. OpenSSL I wouldn't exactly hang my
hat on being that it's low severity, but it also wouldn't look so good.
Since we are already making changes and it's pretty low risk, why not
just get it done? Both consumers in LFS itself are fine. OpenSSH is
fine, p11-kit is fine... In fact, a quick perusal of the diff,
specifically at header changes, has only further increased my confidence
that it should just be taken care of along with the others.
OK, I'll release -rc2. I do not think we need to invalidate the tags we
have already done in BLFS. For kernels 4.18 and 1.18.1 I did:
make INSTALL_HDR_PATH=dest headers_install
find dest/include \( -name .install -o -name ..install.cmd \) -delete
and then
$ diff -Naur linux-4.18/dest linux-4.18.1/dest
diff -Naur linux-4.18/dest/include/linux/version.h
linux-4.18.1/dest/include/linux/version.h
--- linux-4.18/dest/include/linux/version.h 2018-08-16
10:35:06.647129120 -0500
+++ linux-4.18.1/dest/include/linux/version.h 2018-08-16
10:35:59.127620298 -0500
@@ -1,2 +1,2 @@
-#define LINUX_VERSION_CODE 266752
+#define LINUX_VERSION_CODE 266753
With that small a change, an in-place update of kernels will not change
any other packages.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
