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.3512.1571221641870799283 for ; Wed, 16 Oct 2019 03:27:22 -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-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 450D710DCC81; Wed, 16 Oct 2019 10:27:21 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-232.ams2.redhat.com [10.36.116.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id D0AA75D6A9; Wed, 16 Oct 2019 10:27:19 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553) To: David Woodhouse , devel@edk2.groups.io, "Wu, Jiaxin" , "Wang, Jian J" , Bret Barkelew Cc: Richard Levitte References: <20190927034441.3096-1-Jiaxin.wu@intel.com> <6bb5d2f6-ec6f-1766-e19b-03fd45c1bc12@redhat.com> <9A4966EE-76CD-465C-A6CA-70DD9E38D834@infradead.org> <850a81a8-2cdc-0708-4ff7-db9825fdaedc@redhat.com> <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> <5c33b6c2-c8b0-aa64-a85f-06bdc3c69843@redhat.com> <1400b3e6c04f3422a1ba0bef844664aa84c6ff33.camel@infradead.org> <72205ed7-e848-62a0-11d2-408d5b070cc7@redhat.com> <7356801d-0b64-6059-a737-aa5ddd2d297b@redhat.com> <7a3736ba-6bf6-1420-8471-4678e7340580@redhat.com> <8c24b2d143962351667a9f165c49d7beeb0df570.camel@infradead.org> From: "Laszlo Ersek" Message-ID: <566b312f-cb8e-0905-d61c-2e3445251b50@redhat.com> Date: Wed, 16 Oct 2019 12:27:18 +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: <8c24b2d143962351667a9f165c49d7beeb0df570.camel@infradead.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.64]); Wed, 16 Oct 2019 10:27:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/16/19 11:40, David Woodhouse wrote: > On Tue, 2019-10-15 at 19:34 +0200, Laszlo Ersek wrote: >> Ehh, I failed to ask the actual question. >> >> Is it OK to call X509_VERIFY_PARAM_set1*() multiple times -- basically= , >> every time just before we call X509_verify_cert()? >> >> My concern is not with the crypto functionality, but whether we could = be >> leaking memory allocations. >=20 > You had to ask yourself that before approving the original version of > TlsSetVerifyHost(), didn't you? Because the TlsLib API hasn't imposed > any restriction on calling TlsSetVerifyHost() more than once... You are correct, of course. I seem to recall that I hand-waved that question away, seeing that TlsSetVerifyHost() simply passed the hostname (the pointer to the char array) into an OpenSSL API. I guess when I first looked at that call with any kind of focus, I wasn't *that* concerned about the life-cycle yet... >=20 > The answer is yes, btw =E2=80=94 it's fine.=20 Thanks! >=20 > Note also my observation that we should insist on TlsSetVerifyHost > being called at *least* once, or the connection should fail. >=20 I wonder if we could make this an implementation detail in edk2 *first*, while a matching USWG Mantis ticket were in progress. Thanks Laszlo