From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120])
 by mx.groups.io with SMTP id smtpd.web12.2365.1589361382118244681
 for <devel@edk2.groups.io>;
 Wed, 13 May 2020 02:16:22 -0700
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ihjC+q/4;
 spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1589361381;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=uyiR54/ph9pRVEfg4sR4fppFZlHUhzkL785d3MY20xo=;
	b=ihjC+q/4jU81ecBxJySrDBYahZWabI9JHl1aPz91Rbs6vECkM7ROGFJIkusiLsjn3uThRo
	3Z3BhowAVxXtTbIO3yQ3DMiR1mQlufm3a9Zp6ysiFiG7TDsGXR4x8DCqs3r9MFzqXjbR1b
	3+1LHJPjOQ1bGnlX/XFoVZSa48lKF3o=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-34-60QjYVXINiGWAXV8aCYgSQ-1; Wed, 13 May 2020 05:16:17 -0400
X-MC-Unique: 60QjYVXINiGWAXV8aCYgSQ-1
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CDBB3107ACF6;
	Wed, 13 May 2020 09:16:15 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-95.ams2.redhat.com [10.36.115.95])
	by smtp.corp.redhat.com (Postfix) with ESMTP id C82005C1BB;
	Wed, 13 May 2020 09:16:13 +0000 (UTC)
Subject: Re: [edk2-devel] [PATCH V4 00/27] Disabling safe string constraint assertions
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
 "devel@edk2.groups.io" <devel@edk2.groups.io>,
 Vitaly Cheptsov <cheptsov@ispras.ru>
Cc: Andrew Fish <afish@apple.com>, =?UTF-8?Q?Marvin_H=c3=a4user?=
 <mhaeuser@outlook.de>, "Gao, Liming" <liming.gao@intel.com>,
 "Gao, Zhichao" <zhichao.gao@intel.com>
References: <20200511154121.3878-1-cheptsov@ispras.ru>
 <MN2PR11MB446155752A1BB7EADB0F8F69D2A10@MN2PR11MB4461.namprd11.prod.outlook.com>
 <44ac1ca1-953a-21a2-0c9e-c83aca153b0b@redhat.com>
 <MN2PR11MB44618F21D9B49CF915B69142D2BE0@MN2PR11MB4461.namprd11.prod.outlook.com>
From: "Laszlo Ersek" <lersek@redhat.com>
Message-ID: <9347b132-b0e9-5b26-f993-910aafc9d6ae@redhat.com>
Date: Wed, 13 May 2020 11:16:12 +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: <MN2PR11MB44618F21D9B49CF915B69142D2BE0@MN2PR11MB4461.namprd11.prod.outlook.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi Mike,

On 05/12/20 20:18, Kinney, Michael D wrote:

> What if there is a 
> DebugLib implementation of the DebugLib class that 
> does not depend on DebugCommonLib.

There need not be a link failure in this case either, if the DebugLib
instance in question provides the DebugCommonLib API implementations too.

Anyway I don't want to obsess about this. I'm just sad there are zero
acceptable solutions apparently to the 100% valid problem statement that
Vitaly submitted last August, in TianoCore#2054. (Asserting properties
of untrusted external data is *asinine*.) But then, if Vitaly proposes
to update all DebugLib instances one by one, that gets shot down because
"too many DebugLib instances in platforms". And if Vitaly extracts the
common bits so that only the common bits have to be updated, that gets
shot down by "we don't support this kind of dependency, please update
all DebugLib instances instead".

Let's just be honest and call DebugLib frozen forever.

Laszlo