From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (NAM11-BN8-obe.outbound.protection.outlook.com [40.107.236.134]) by mx.groups.io with SMTP id smtpd.web11.4290.1617298641620323345 for ; Thu, 01 Apr 2021 10:37:22 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@microsoft.com header.s=selector2 header.b=UxDH89oo; spf=pass (domain: microsoft.com, ip: 40.107.236.134, mailfrom: bret.barkelew@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hJS1HG8s00rZ6HzJFTrgZvjie484mldxmhPh2LuUhQiIZmFyXt7O1HZ9o/bgSBOt9k+yhLJBTlvG8+4wki3f+Jsks5zntlqsUlWuhaUxTGDQTzn5GdSouEGGTU2YEOrXqVfVS1FoB/dNVcFg+H5tCu5PDt8GVEKSXuUGk7/z1pE33aKDsbEK319xBJP15Hkh1vpeu/6nmx1DhC9BjL+/vXuMqemH+7dKl1cy68R5SAFmbFPshYw4tK0c7ZzJbCGFhOMzby5UPwq2QN0AMOWtr2WdWzl17Aaf1hS5j2cBc4E1tSF08p9IJ8DZzLpTwszLlPuHbVTWgMd5j8rgmrt7og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fvA0zsErtxpm3/fem8u09V7C1wwu4NgydgKrtNYxeYA=; b=gLpUo1IE1IWJs5L/YcFm8ZryFlOz8CQ/D7aueb5jXa/isIiwLezmkMYnCp6M8juoN7OOWGwrrN627orUXLbAm/FpdT756vsn/K1a2H+ww1MgM7ICo8R3cq7SiRM4hEBX9iS1+enQ7UQENHFNxsfe6e7wnW3qrtTo4ieiLaFS0TyqgeNUqlOLNBX3iHEh6T9FfuDAxPZTbtEgZTYw/zoeV+alJcvUdmKHzLr6KmgNnw5axWjEApBOa9WqbXOLQgEoZ1P/Efly5tcviguH9/ubzdE7yW9dadLCoBE68rQZxBDsDGv8WdNwrIOkql5fgHsIUm++MYd7Xsl0SsQclq56Ag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fvA0zsErtxpm3/fem8u09V7C1wwu4NgydgKrtNYxeYA=; b=UxDH89ookU8CqXGAEL06OS6iiuhoCXjsSztzELSDHWQjuOQ9ocxQH7gVCBOnlbEFHXCaIO/rdAvb05EbdHF5XG2cpGho+MBhpmC9XF2dMSm0KPXD+othoY4O9Tr8Uqlb0WHJy7uNnCVT93fiRhFcmP9TJycQIcAsFmhjjFK/8Vs= Received: from MW4PR21MB1907.namprd21.prod.outlook.com (2603:10b6:303:71::8) by MW4PR21MB2003.namprd21.prod.outlook.com (2603:10b6:303:68::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.6; Thu, 1 Apr 2021 17:37:19 +0000 Received: from MW4PR21MB1907.namprd21.prod.outlook.com ([fe80::adcb:b821:ee26:3348]) by MW4PR21MB1907.namprd21.prod.outlook.com ([fe80::adcb:b821:ee26:3348%8]) with mapi id 15.20.4020.009; Thu, 1 Apr 2021 17:37:19 +0000 From: "Bret Barkelew" To: "devel@edk2.groups.io" , "zhichao.gao@intel.com" , "afish@apple.com" , Laszlo Ersek CC: Jeff Brasen , "Wang, Jian J" , "Wu, Hao A" , "Yao, Jiewen" , Liming Gao , "Ni, Ray" Subject: Re: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLib: Allow BMP with extra data Thread-Topic: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLib: Allow BMP with extra data Thread-Index: AQHXIAolx3JfgU4qrkW2Ofg9DVVe4qqR1zIugAErSICAAEE1AIAAMr6AgACPbgCAB7/CcIAEMoGD Date: Thu, 1 Apr 2021 17:37:19 +0000 Message-ID: References: <70c26f78d461d1b8021462d3c3fe6eb717b19193.1616520420.git.jbrasen@nvidia.com> <7d5c8dd7-680c-98e6-b8a0-084704ca3021@redhat.com> <4834AF3E-A929-4911-AB8E-0665AB2033FB@apple.com>, In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-04-01T17:26:07.0216087Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: edk2.groups.io; dkim=none (message not signed) header.d=none;edk2.groups.io; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [71.212.153.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3466ce53-99b4-4593-6e9f-08d8f534cccb x-ms-traffictypediagnostic: MW4PR21MB2003: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IQHKuVbnyIXK8f4/qEJwDBkoHVIhQl4JsM345LtUQVZpiiVGZaTRbkzV5EKWvkCNqj+POUjrOy//ZY7TzSe2RPW4lL9P1Nkx4jRX/QSaEyVr7A4D830ZGG0Db2o0OjqdLuOsgAz9App7ohTBIrJLJ3VGPRXcQoHnDFoTW+t/oeIKEKF13GFQPnjA0aptCaAJGdy+YBuFUj2T2+lqCkfeebMk7m5zHocCM5OqXrZNIYZdRSe4ACVZ9+IdlBA5JUV/+qDx9VP79ZpV0iPEmzzTGDRoz3nV8JMSPCEcA6L5XbUqYuJNZS8nP0eF4njKw22qtwqP/qCWZIrtLj6NObj47jXlNeRup9MxD5+7OW1VBpuM42iZAI8JPyefhXJ3Fn794H1/BEdOdX23UP1HxeRR5+Jf6c5ul4GO8eY1J8LGEd/d5PxlAm/LQHQw4bF5gFJQ0LBTL3QiDQglPZ0hpbOLOFq5L6NhXCwqcs9xMbz6hjm2iU7WuUL3jks0xHh2EnIGx0/eKh2Sow3LZPU4d3QX9VThxXCXwv0ZElx6mutMOzeK+d2UCgUHSvClloF1eHYUAfUV+ZmPdEPcM+zcKR0UN+ZJproFSWq34JKP/8v6W9hPAg6wmBzUlDVy2N1vaRDCo3X8ujBffkbV/1K0wuQS8T18KaUPIbwyhQmMqqoWJnbxCpE+GalkPxtrzFu9AvqpTcNL7ZBe/FZs9+DRzT80CzafSufOtwu4XTURIxCrbQw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR21MB1907.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(346002)(396003)(39860400002)(366004)(376002)(136003)(71200400001)(86362001)(478600001)(82960400001)(7696005)(166002)(4326008)(966005)(83380400001)(33656002)(66476007)(76236003)(82950400001)(110136005)(53546011)(7416002)(26005)(8936002)(5660300002)(52536014)(2906002)(186003)(66446008)(8676002)(99936003)(8990500004)(64756008)(66946007)(55016002)(66616009)(316002)(76116006)(54906003)(9686003)(66556008)(6506007)(38100700001)(10290500003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?7UxFa65ju/23cZf6EfxRPZQH60xefAojLx9T3ziwHduhP+ctRvT21IN9?= =?Windows-1252?Q?F2cC9bvTOdCmPJ3pjzxb2tLVrRI8HOlO68m0g3jqdt9onyYdwztT6GeO?= =?Windows-1252?Q?ktL4NYK0tc8oBGPGo7Z4dcgPQRkEhF5bpuIx04O8/CBduyxlTvXJUybn?= =?Windows-1252?Q?fNHtnss5w2SVDMPOXiwxujPqLItalC0ZHyTGzMjKBAM9upOuw1rmhHHJ?= =?Windows-1252?Q?iOKCMRhI+rfgBxAQuqh1QVnENlEWUwPiwQuPk4ZQfiGBOzXg5TIaJmzH?= =?Windows-1252?Q?98/E+Le8L1AlO0dRLIZBaJdhPu51m7TtmKXQxv+iM6dLeOPhOUacvfOu?= =?Windows-1252?Q?LQde0vwfuDE9LpZ9nYDIYTp9zKaaY0I7RBQRmLlu//PVeahqagrjqt5x?= =?Windows-1252?Q?+cJs2VQEO1lOYsc/cTp4JLWm5PW2RRbXGTrKNn7KxetP+kNELXdDa1b6?= =?Windows-1252?Q?D/jsXa1qKrMlFL2X3vThg25/qBpHTm11QEHsvmR8W4h5lksHbyer9MWP?= =?Windows-1252?Q?aC3PdSg7n02hETSFu8/F4lgh9xjHcUxaj86pKeH9DYmfggxUJabKvEwE?= =?Windows-1252?Q?S1VTu+3HyRqw1u/Ac/m61A3Ikt7kFGXIi2e5yzyMQFtVAoNHzK3bvmby?= =?Windows-1252?Q?DdXRS2J8nCzMFwfQRs8mu5PTi1LTQoaN178b45hwWnZyILwLVT1vP0oe?= =?Windows-1252?Q?dgZIOSGHrPS/UuqVG6aGVVcGIrSKGELJeCozZBsbTKy7URzmQfnfFFW7?= =?Windows-1252?Q?xN6JBLC3pquQOKWT1JdcziO9uVt5IxRnAL6rfE/RSi8ovCndhX2U2qOG?= =?Windows-1252?Q?eyR8eLqiMs2FwIspAq9BI+660MASL7uT+hm96ycXzisFEtKSIo0Bi66R?= =?Windows-1252?Q?EGWzqxnOzq0kHyItcgNMKMN41K4vee+1T/EYgr7xdZ5878mcSyUGcJHD?= =?Windows-1252?Q?ApHPflzszqbm0jdJ/r5JbA6mlxDVOZqe4jO+EDH2YgxmFExqwIp1N83f?= =?Windows-1252?Q?CegpOB9Ln13P5mhq7+kI0qQwuHIDMzOiKOkHp0QNAqMaCyTUt5AwCU6d?= =?Windows-1252?Q?58WThap4Guhca4MmnwgK6AUueN/RZIMNxMAXFYFFvN60iPFk5NymSd5N?= =?Windows-1252?Q?y5xYDVA9UVUYAXAwOLaKLtLmVAVs+oJ7raImxPUKYEDqWQswR2ty3x1h?= =?Windows-1252?Q?OeTTkN/jByQtUhssdU1gzmM9vAHD9ZAbRPOPLUVRM0oBcE7EJLVGGGPa?= =?Windows-1252?Q?/xY5m6FkWhZodzEWWknDWZhSsMGlOgt66vdZrrDVKDXOu/kkXKP8yIvm?= =?Windows-1252?Q?HRohbjaKny5jBmkVIZlIzuUBg2JG4b04UbVJMHimP0cL6qzXKP6TITBM?= =?Windows-1252?Q?icTbwpU19WyajGtA7e97eK27hyoUbcurd/CSXp/LI6PdOySp3To64Ioj?= =?Windows-1252?Q?uwTeRWdf1Yh5HYapiEAfRQ=3D=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR21MB1907.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3466ce53-99b4-4593-6e9f-08d8f534cccb X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2021 17:37:19.4370 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eghXzxpgKYzhUaH3dLjQ3ZE+qnrk4jBNRi4a/NG5XMDBCCMsdpqVrHOVVUwpyQM7NS7Ie791C5wVqstmcR8EGA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR21MB2003 X-Groupsio-MsgNum: 73619 Content-Language: en-US Content-Type: multipart/related; boundary="_004_MW4PR21MB1907C8525208513CBA507D99EF7B9MW4PR21MB1907namp_"; type="multipart/alternative" --_004_MW4PR21MB1907C8525208513CBA507D99EF7B9MW4PR21MB1907namp_ Content-Type: multipart/alternative; boundary="_000_MW4PR21MB1907C8525208513CBA507D99EF7B9MW4PR21MB1907namp_" --_000_MW4PR21MB1907C8525208513CBA507D99EF7B9MW4PR21MB1907namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with the proposal for a deeper security review. I also would suggest that we can provide tooling with BaseTools to check a= nd/or correct the format of a BMP to match what the code expects (since the= re seems to be ambiguity in the spec/implementation). We=92ve got a validat= or in Mu and would be happy to put together some patches to at least get th= is started for the community to hammer on. - Bret From: Gao, Zhichao via groups.io Sent: Monday, March 29, 2021 6:35 PM To: devel@edk2.groups.io; afish@apple.com; Laszlo Ersek Cc: Jeff Brasen; Bret Barkelew; Wang, Jian J; Wu, Hao A<= mailto:hao.a.wu@intel.com>; Yao, Jiewen; Limin= g Gao; Ni, Ray Subject: Re: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLi= b: Allow BMP with extra data The patch would let the BMP file that with a bunch of data pass the check,= no matter the data is valid or not. Do we have other docs to descript whic= h data is allowed and valid? Correct the Cc mail address and invite more experts for security review. Thanks, Zhichao From: devel@edk2.groups.io On Behalf Of Andrew Fish= via groups.io Sent: Thursday, March 25, 2021 11:00 AM To: edk2-devel-groups-io ; Laszlo Ersek Cc: Jeff Brasen ; bret.barkelew@microsoft.com; Wang, J= ian J ; ao.a.wu@intel.com Subject: Re: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLi= b: Allow BMP with extra data On Mar 24, 2021, at 11:26 AM, Laszlo Ersek > wrote: On 03/24/21 16:25, Jeff Brasen wrote: Some of the logo files we received for the group that makes our assets lik= e this (not sure what tool they were created with) look like they pad the B= MP size to 8 bytes. TranslateBmpToGopBlt: invalid BmpImage... BmpHeader->Size: 0xE1038 BmpHeader->ImageOffset: 0x36 BmpImageSize: 0xE1038 DataSize: 0xE1000 TranslateBmpToGopBlt: invalid BmpImage... BmpHeader->Size: 0x2A3038 BmpHeader->ImageOffset: 0x36 BmpImageSize: 0x2A3038 DataSize: 0x2A3000 TranslateBmpToGopBlt: invalid BmpImage... BmpHeader->Size: 0x5EEC38 BmpHeader->ImageOffset: 0x36 BmpImageSize: 0x5EEC38 DataSize: 0x5EEC00 So, each of these has 2 bytes of padding at the end of the file. We could = write a tool that would do the same size recalculation in order to update t= he size in the header and remove the two bytes but it seems that this is a = valid BMP file and it doesn't seem correct that UEFI is rejecting it. I can= update the commit message with more context if needed as well. If there's a spec describing the BMP format, Yes and there are various flavors as at some point I had some graphics giv= en to me in a format that did not work (I think it was BITMAPV4HEADER) :(. https://en.wikipedia.org/wiki/BMP_file_format#cite_note-DIBhelp-5 edk2 supports =91BM=92 and the BITMAPINFOHEADER DIB. I seem to remember DI= Bs are defined by the size. So =91BM' is a Microsoft Spec: https://docs.microsoft.com/en-us/previous-versions/ms969901(v=3Dmsdn.10)?r= edirectedfrom=3DMSDN The quote in that spec is: The file extension of a Windows DIB file is BMP. The file consists of a BI= TMAPFILEHEADER structure followed by the DIB itself. Unfortunately, because= the BITMAPFILEHEADER structure is never actually passed to the API, not ev= ery application that generates BMP files fills out the data structure caref= ully. To add to this confusion, the "proper" definition of the structure is= at odds with the documentation. Properly, the data structure contains the = following fields: The explanation of size field is: A DWORD that specifies the size of the file in bytes. The Microsoft Window= s Software Development Kit (SDK) documentation claims otherwise. To be on t= he safe side, many applications calculate their own sizes for reading in a = file. I would say that is not exactly a ringing endorsement from a spec point of= view on depending on that field. So it seems like that patch may be reason= able, but we should triple check it does not break any security related ass= umptions. Thanks, Andrew Fish and edk2 is needlessly strict, and the check can be relaxed without security risks, then I think a patch would be fair. Thanks Laszlo --_000_MW4PR21MB1907C8525208513CBA507D99EF7B9MW4PR21MB1907namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I agree with the proposal for a deeper security rev= iew.

 

I also would suggest that we can provide tooling wi= th BaseTools to check and/or correct the format of a BMP to match what the = code expects (since there seems to be ambiguity in the spec/implementation)= . We=92ve got a validator in Mu and would be happy to put together some patches to at least get this started for th= e community to hammer on.

 

- Bret

 

From: Gao, Zhichao via groups.io=
Sent: Monday, March 29, 2021 6:35 PM
To: devel@edk2.groups.io; afish@apple.com; Laszlo Ersek=
Cc: Jeff Brasen; Bret Barkelew; Wang, Jian J; Wu, Hao A; Yao, Jiewen; Liming Gao; Ni, Ray
Subject: Re: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSu= pportLib: Allow BMP with extra data

 

The patch would let the BMP file that with a bunch = of data pass the check, no matter the data is valid or not. Do we have othe= r docs to descript which data is allowed and valid?

 

Correct the Cc mail address and invite more experts= for security review.

 

Thanks,

Zhichao

 

From: devel@edk2.groups.io <devel@edk2.gr= oups.io> On Behalf Of Andrew Fish via groups.io
Sent: Thursday, March 25, 2021 11:00 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Laszlo Ersek= <lersek@redhat.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>; bret.barkelew@microsoft= .com; Wang, Jian J <jian.j.wang@intel.com>; ao.a.wu@intel.com
Subject: Re: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSu= pportLib: Allow BMP with extra data

 

 

 

On Mar 24, 2021, at 11:26 AM, Laszlo Ersek <lersek@redhat.com> wrote:

 

On 03/24/21 16:25,= Jeff Brasen wrote:

Some of the logo files we received for the group = that makes our assets like this (not sure what tool they were created with)= look like they pad the BMP size to 8 bytes.

TranslateBmpToGopBlt: invalid BmpImage...
  BmpHeader->Size: 0xE1038
  BmpHeader->ImageOffset: 0x36
  BmpImageSize: 0xE1038
  DataSize: 0xE1000
TranslateBmpToGopBlt: invalid BmpImage...
  BmpHeader->Size: 0x2A3038
  BmpHeader->ImageOffset: 0x36
  BmpImageSize: 0x2A3038
  DataSize: 0x2A3000
TranslateBmpToGopBlt: invalid BmpImage...
  BmpHeader->Size: 0x5EEC38
  BmpHeader->ImageOffset: 0x36
  BmpImageSize: 0x5EEC38
  DataSize: 0x5EEC00

So, each of these has 2 bytes of padding at the end of the file. We could = write a tool that would do the same size recalculation in order to update t= he size in the header and remove the two bytes but it seems that this is a = valid BMP file and it doesn't seem correct that UEFI is rejecting it. I can update the commit message with m= ore context if needed as well.


If there's a spec describing the BMP format,

 

Yes and there are various flavors as at some point = I had some graphics given to me in a format that did not work (I think it w= as BITMAPV4HEADER) :(. 

 

 

edk2 supports =91BM=92 and the BITMAPINFOHEADE= R DIB. I seem to remember DIBs are defined by the size. So =91BM' is a Micr= osoft Spec:

 

The quote in that spec is:

 

The file extension= of a Windows DIB file is BMP. The file consists of a BITMAPFILEHEADER = ;structure followed by the DIB itself. Unfortunately, because the BITMAPFILEHEADER&n= bsp;structure is never actually passed to the API, not every application that generates= BMP files fills out the data structure carefully. To add to this confusion= , the "proper" definition of the structure is at odds with the do= cumentation. Properly, the data structure contains the following fields:

 

The explanati= on of size field is:

A <= span style=3D"font-size:10.5pt;font-family:"Segoe UI",sans-serif;= color:#171717">DWORD that specifies the size of the file in bytes. The Microsoft Windows Software D= evelopment Kit (SDK) documentation claims otherwise. To be on the safe side= , many applications calculate their own sizes for reading in a file.=

 

I would say that is not exactly a ringing endorseme= nt from a spec point of view on depending on that field. So it seems like t= hat patch may be reasonable, but we should triple check it does not break a= ny security related assumptions. 

 

Thanks,

 

Andrew Fish

 

and edk2 is needle= ssly
strict, and the check can be relaxed without security risks, then I
think a patch would be fair.

Thanks
Laszlo



 

 

--_000_MW4PR21MB1907C8525208513CBA507D99EF7B9MW4PR21MB1907namp_-- --_004_MW4PR21MB1907C8525208513CBA507D99EF7B9MW4PR21MB1907namp_ Content-Type: image/png; name="F0EC9BD5722B471983D77D317B3A9240.png" Content-Description: F0EC9BD5722B471983D77D317B3A9240.png Content-Disposition: inline; filename="F0EC9BD5722B471983D77D317B3A9240.png"; size=140; creation-date="Thu, 01 Apr 2021 17:37:18 GMT"; modification-date="Thu, 01 Apr 2021 17:37:18 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAsQAAAABCAYAAADZ77itAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAhSURBVEhL7cMBDQAACAMg+5cygQkeRoMIG9WT VVXVn7MHYi5moJeByLMAAAAASUVORK5CYII= --_004_MW4PR21MB1907C8525208513CBA507D99EF7B9MW4PR21MB1907namp_--