From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by mx.groups.io with SMTP id smtpd.web12.20.1571070043954278384
 for <devel@edk2.groups.io>;
 Mon, 14 Oct 2019 09:20:44 -0700
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com)
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.redhat.com (Postfix) with ESMTPS id 7CE701056F8A;
	Mon, 14 Oct 2019 16:20:43 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-254.ams2.redhat.com [10.36.117.254])
	by smtp.corp.redhat.com (Postfix) with ESMTP id EDD2F196AE;
	Mon, 14 Oct 2019 16:20:41 +0000 (UTC)
Subject: Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553)
From: "Laszlo Ersek" <lersek@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>, "Wu, Jiaxin"
 <jiaxin.wu@intel.com>, "devel@edk2.groups.io" <devel@edk2.groups.io>,
 "Wang, Jian J" <jian.j.wang@intel.com>,
 Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Richard Levitte <levitte@openssl.org>
References: <20190927034441.3096-1-Jiaxin.wu@intel.com>
 <D827630B58408649ACB04F44C510003625987E2C@SHSMSX107.ccr.corp.intel.com>
 <69774fe6-ea00-44b9-5468-c092dea6cd36@redhat.com>
 <8106467c9f4132c831d0aa604e897fe9d4dda12a.camel@infradead.org>
 <895558F6EA4E3B41AC93A00D163B727416F5D921@SHSMSX107.ccr.corp.intel.com>
 <777053db79600eb90a19945700293d14f4978344.camel@infradead.org>
 <6bb5d2f6-ec6f-1766-e19b-03fd45c1bc12@redhat.com>
 <9A4966EE-76CD-465C-A6CA-70DD9E38D834@infradead.org>
 <850a81a8-2cdc-0708-4ff7-db9825fdaedc@redhat.com>
 <a1077c0ad65a75e596f2ff732f5e68b3770b75a2.camel@infradead.org>
 <23699ae3-10c2-037c-b3f5-ac8f5bea1fb7@redhat.com>
 <895558F6EA4E3B41AC93A00D163B727416F7E4AB@SHSMSX107.ccr.corp.intel.com>
 <6939ba4e-6c77-0769-4ac2-c3ba1ea9a0b7@redhat.com>
 <44468659be80e9bf1886e7b6f8f3aa77044b5fd6.camel@infradead.org>
 <5bbadb29-36f2-1054-fd41-5577d59c9290@redhat.com>
 <fd0fded041b846b792d8ecee13864a4b791a1afe.camel@infradead.org>
 <5c33b6c2-c8b0-aa64-a85f-06bdc3c69843@redhat.com>
Message-ID: <cba79372-6bf9-2499-bba8-7b5974cd5e9f@redhat.com>
Date: Mon, 14 Oct 2019 18:20:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <5c33b6c2-c8b0-aa64-a85f-06bdc3c69843@redhat.com>
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.64]); Mon, 14 Oct 2019 16:20:43 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 10/14/19 18:15, Laszlo Ersek wrote:

> David: another way to prevent the regression is to commit the current
> patches, but disable them with a BOOLEAN PCD, by default. (This need not
> be a feature PCD; it could even be dynamic.) Then platforms accepting
> the SAN/GEN_IP regression temporarily could enable the PCD. This
> solution would permit a separate (follow-up) series for the SAN/GEN_IP
> case. We could file a reminder BZ now, and implement the "easy" solution
> when we next rebase the openssl submodule. Would that be tolerable?

... to clarify, in this case, the upstream edk2 project should *not*
claim to have fixed CVE-2019-14553, until the reminder BZ is also
closed! The new BZ should actually block TianoCore#960.

Thanks
Laszlo