Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wVM9h-001u3H-0Z for pgsql-bugs@arkaria.postgresql.org; Fri, 05 Jun 2026 04:27:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wVM9e-009ylT-2m for pgsql-bugs@arkaria.postgresql.org; Fri, 05 Jun 2026 04:27:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wVM9e-009ylK-1q for pgsql-bugs@lists.postgresql.org; Fri, 05 Jun 2026 04:27:34 +0000 Received: from mail-yx1-xb130.google.com ([2607:f8b0:4864:20::b130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wVM9a-00000001MFB-2Gve for pgsql-bugs@lists.postgresql.org; Fri, 05 Jun 2026 04:27:32 +0000 Received: by mail-yx1-xb130.google.com with SMTP id 956f58d0204a3-6603246b66dso1605816d50.1 for ; Thu, 04 Jun 2026 21:27:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780633648; cv=none; d=google.com; s=arc-20240605; b=WtPa6ni2rD6iasR5yf2sVO7w4XIgJYy9qehZiuBSuDrPwitiyVE7CeMBhL218Gd6sU hyH5HnX8AWZVlU6VHVbgm80LaOKWWuTto4mC4lzE0d4AkF8VxA++rC5L489WkRXVAJJF /ckjCOFpHrZTih28PO+05+9VrAQ5RoC4k8w0NOsraqw9qjdBzaOdB60xsgcIG5qEVXWm RtR8H00QQbIX7Fnw5h6sK8OfYrT+mWT01LnAWGklrq1eZxc19XCp6dIa/pTXFj6Yg3ox P31PfHpUC4oP0e+LY+22v4ENOHmVqWTSZegEIwI8He/6lqQRxaRxeLHkmdM2mm4JEtrA /cvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=rWbvxdC/KoBeHjtTU14Zv4dUoV0Pi4hsW0yZRk/fDlU=; fh=LHIj7/NepvKESbWrlYVKU++LcM0KxbH/PsfRtMRzmok=; b=RzuRFphAxCWdytZ5kt4eCRDS4HeI1Qak4nl6XUDq1X9IxngT5V0EwzKOqJaDarTPZa tW3R+Z6ZDFyRxqseMXaCVUIsdnLn645l4yUBwwCHOm5MHzprxovWomgaEdYkhITcPLM5 bJ2ZJ+QucGS4Yve8IdyOAGYN4JLEB1413OHzdV/+dTdk6PFE22ZCjSPVpHEeluMcAC/Q Gk8MhwuwN1nBqSoGSCGaqoOl9wDFEm825xyYm/pyjLL7B50B5PdWCbLDgZnYihV63xsy d2kT2880kFdC4d8kdTsrXhvIz1qJ57d4IMiu5IcYcpabpmy9ZQ6f7jVHg47o0Z+uZPIG wNAw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780633648; x=1781238448; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=rWbvxdC/KoBeHjtTU14Zv4dUoV0Pi4hsW0yZRk/fDlU=; b=lESXRP4cgj/B6vEj9snlR0A/eSLzsU+FL1uW9IWX8wUMx/LemP+iP9ceCz0Nz2/Eo2 TRVBvZfRoduO61VIwA8iu07FG4CwIHa4eSpOvoUIeYsYlBExRcgMl9vrI37HsgvvM/Do RDzDF5nb2AiBvRQRGuvZE4uJ8faQqon3GW+DKUnkzPxgt7ORzOSsOwSkfAA89e04U5Hy 8QHzrJWff+hlTIGsXCCuT7iPafnc7uYygUdCPEfXPXgrr/uQX7ITpSmHNGZoKMU43JEr y9Sed2WqOSU1ajFor6LoDF9MFZPgZhjCbna6GbF1IM0VoA7LNliuuI8iJ+6JmuD1hDNa 3s8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780633648; x=1781238448; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rWbvxdC/KoBeHjtTU14Zv4dUoV0Pi4hsW0yZRk/fDlU=; b=dHavkt9ImI/tysacxgZ62+Vt/yvizckk4W8HIp/TWmR8LetrpTNpXceJz4l+ktcDxo oL3Y5H/oRFsAVCdid1R8ygITvMTP7hyOvL+wiTiq4RmD3iwS0GZA7UJICwuzGwJCM9Yu gX4+lV9U51C/hesFEdOhJbrnw4hbhzUxGFlcmPuRyU9dQ1yL/Z3wrnEwXGo1DevMMjHV EycmcHHKTcG77K8VAcTRGBzxmTto32vAAbJt5929Kt+JeL8ZeDhCOiYbB5Ed8IpGDukL ZnjexSOjemr+teXHUY5Z4EuYpdCdsojfLQf+tBe66GQbmgXTtwfFwKdr3ziVVR0bnJbn cjEQ== X-Forwarded-Encrypted: i=1; AFNElJ90AHualO89oQ7Vtv0uH64h70UrRA/CFdm7kdLspcvAPWzY3vduHj73YhlNrKHdPBBVqIN0J3cAuCHW@lists.postgresql.org X-Gm-Message-State: AOJu0YwWvoK8v/qx16Iy421U0sFVw88D70Q+44NvmnEHL5vr+EEnpHrF FURLWEEUg9BrFCHnpNc38YbCHgjRUaBFFToku4bxwHPz1oAAo6ewG+YyXn/dWZYsBUzzXtKcyUf 1UzxqzStzA2c6yHIekOTI2dRowE8b/e0= X-Gm-Gg: Acq92OHbfUhHIIpPIMEIdB9uW50VMtrdshb6VnWEP5fybQ6koxifi1IkPmRc3qndih4 fgPOfwA8H/EOyKqbmrD/TIy7kdPXJk4fJDfh1h3YmIQqeeMQJ0gQwHgOYV1RAjtNuHK2718epXa Dil2HYFikBTe8X7+GUr+X8gPQ2/e53q0Xbj5g1f55Fm+O/Uao7M6BYj83Uhm7ANiFqywg+yeEBG CBGKJiYzk0EsP7hLOtMq1tw2ujI8+FgyNg8aqe6dvxdermCctV6sOxWUXqGcrOMs2nudhsf2vde 6pA+khKSwtWEXk52x2w7MJVwEq4Fx8qNtG+AT1gNK0+mpCnO X-Received: by 2002:a05:690e:169e:b0:651:bb21:e7fb with SMTP id 956f58d0204a3-66106fada73mr1564449d50.54.1780633648353; Thu, 04 Jun 2026 21:27:28 -0700 (PDT) MIME-Version: 1.0 References: <19506-9478f3012ecc2328@postgresql.org> In-Reply-To: <19506-9478f3012ecc2328@postgresql.org> From: Ayush Tiwari Date: Fri, 5 Jun 2026 09:57:16 +0530 X-Gm-Features: AVVi8CcC8j2JLob49fI_NNpBvycGSHIdWt3hoOZ6C3Q3yD1k8Tixc60x3HpFz0A Message-ID: Subject: Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path To: gabriele.bartolini@gmail.com, pgsql-bugs@lists.postgresql.org, Peter Eisentraut Content-Type: multipart/mixed; boundary="000000000000160f5f06537a14fd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000160f5f06537a14fd Content-Type: multipart/alternative; boundary="000000000000160f5c06537a14fb" --000000000000160f5c06537a14fb Content-Type: text/plain; charset="UTF-8" Hi, On Thu, 4 Jun 2026 at 21:23, PG Bug reporting form wrote: > The following bug has been logged on the website: > > Bug reference: 19506 > Logged by: Gabriele Bartolini > Email address: gabriele.bartolini@gmail.com > PostgreSQL version: 18.4 > Operating system: Linux (reproduced under CloudNativePG/Kubernetes) > Description: > > When an extension is installed in a location reached via > `extension_control_path` / `dynamic_library_path` (rather than the > compiled-in package library directory), a LOAD '$libdir/foo' hardcoded > inside an extension's SQL script fails to find the library. PostGIS does > this in its upgrade scripts, so a PostGIS upgrade fails: > > ``` > app=# SELECT postgis_extensions_upgrade(); > NOTICE: Updating extension postgis 3.6.1 > ERROR: could not access file "$libdir/postgis-3": No such file or > directory > CONTEXT: SQL statement "LOAD '$libdir/postgis-3'" > extension script file "postgis--ANY--3.6.3.sql", near line 1530 > ``` > > This is a side effect of the fix for bug #18920 (commit f777d773878). > Commit > 4f7f7b03758 (`extension_control_path`) made the feature work by stripping > the '$libdir/' prefix so that dynamic_library_path is consulted. #18920 > then > restricted that stripping to the function-load path so that a user-issued > `LOAD` keeps the literal '$libdir/' prefix. As a result, a `LOAD` inside an > extension script now also keeps the literal prefix, so > `dynamic_library_path` is never consulted, and the library cannot be found. > > A `LOAD` running inside an extension script should behave like the > extension's function loads (strip '$libdir/'), while a LOAD issued directly > by a user should keep it (the #18920 behaviour). The two can be > distinguished by `creating_extension`. > > Reproduced with the CloudNativePG operator on Kubernetes, but it applies to > any setup using `extension_control_path` / `dynamic_library_path`. > Thanks for the report and the very clear diagnosis, I could reproduce the issue and your analysis matches what I see. The attached patch implements exactly what you suggested: a LOAD running while creating_extension is true strips the simple "$libdir/" prefix (so dynamic_library_path is consulted, like the extension's own function loads do), while a user-issued LOAD keeps the literal prefix and therefore preserves the #18920 behaviour. To avoid duplicating the existing prefix-stripping logic in load_external_function(), I factored it out into a small static helper and reused it from load_file(). Nested paths (e.g. "$libdir/foo/bar") are still left untouched and continue to be expanded by expand_dynamic_library_name() as before. Verified locally that the PostGIS-style reproducer now succeeds when the extension is installed via extension_control_path / dynamic_library_path, that a plain user-issued LOAD '$libdir/foo' still behaves as on HEAD, and that the existing extension regression suites still pass. Regards, Ayush --000000000000160f5c06537a14fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Thu, 4 Jun 20= 26 at 21:23, PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the websit= e:

Bug reference:=C2=A0 =C2=A0 =C2=A0 19506
Logged by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gabriele Bartolini
Email address:=C2=A0 =C2=A0 =C2=A0 gabriele.bartolini@gmail.com
PostgreSQL version: 18.4
Operating system:=C2=A0 =C2=A0Linux (reproduced under CloudNativePG/Kuberne= tes)
Description:=C2=A0 =C2=A0 =C2=A0 =C2=A0

When an extension is installed in a location reached via
`extension_control_path` / `dynamic_library_path` (rather than the
compiled-in package library directory), a LOAD '$libdir/foo' hardco= ded
inside an extension's SQL script fails to find the library. PostGIS doe= s
this in its upgrade scripts, so a PostGIS upgrade fails:

```
app=3D# SELECT postgis_extensions_upgrade();
NOTICE:=C2=A0 Updating extension postgis 3.6.1
ERROR:=C2=A0 could not access file "$libdir/postgis-3": No such f= ile or directory
CONTEXT:=C2=A0 SQL statement "LOAD '$libdir/postgis-3'" extension script file "postgis--ANY--3.6.3.sql", near line 1530 ```

This is a side effect of the fix for bug #18920 (commit f777d773878). Commi= t
4f7f7b03758 (`extension_control_path`) made the feature work by stripping the '$libdir/' prefix so that dynamic_library_path is consulted. #1= 8920 then
restricted that stripping to the function-load path so that a user-issued `LOAD` keeps the literal '$libdir/' prefix. As a result, a `LOAD` i= nside an
extension script now also keeps the literal prefix, so
`dynamic_library_path` is never consulted, and the library cannot be found.=

A `LOAD` running inside an extension script should behave like the
extension's function loads (strip '$libdir/'), while a LOAD iss= ued directly
by a user should keep it (the #18920 behaviour). The two can be
distinguished by `creating_extension`.

Reproduced with the CloudNativePG operator on Kubernetes, but it applies to=
any setup using `extension_control_path` / `dynamic_library_path`.

Thanks for the report and the very clear diagnosis, = I could
reproduce the issue and your analysis matches what I see.
The attached patch implements exactly what you suggested: a
LOAD runnin= g while creating_extension is true strips the simple
"$libdir/"= ; prefix (so dynamic_library_path is consulted, like
the extension's= own function loads do), while a user-issued
LOAD keeps the literal pref= ix and therefore preserves the
#18920 behaviour.

To avoid duplica= ting the existing prefix-stripping logic in
load_external_function(), I = factored it out into a small
static helper and reused it from load_file(= ).=C2=A0 Nested paths
(e.g. "$libdir/foo/bar") are still left = untouched and continue
to be expanded by expand_dynamic_library_name() a= s before.

Verified locally that the PostGIS-style reproducer now suc= ceeds
when the extension is installed via extension_control_path /
dy= namic_library_path, that a plain user-issued
LOAD '$libdir/foo' = still behaves as on HEAD, and that the
existing extension regression sui= tes still pass.

Regards,
Ayush
--000000000000160f5c06537a14fb-- --000000000000160f5f06537a14fd Content-Type: application/octet-stream; name="v1-0001-dfmgr-let-extension-script-LOAD-use-dynamic_lib.patch" Content-Disposition: attachment; filename="v1-0001-dfmgr-let-extension-script-LOAD-use-dynamic_lib.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mq0f90zd0 RnJvbSAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBeXVzaCBUaXdhcmkgPGF5dXNodGl3YXJpLnNsZzAxQGdtYWls LmNvbT4KRGF0ZTogRnJpLCA1IEp1biAyMDI2IDEyOjAwOjAwICswNTMwClN1YmplY3Q6IFtQQVRD SCB2MV0gZGZtZ3I6IGxldCBleHRlbnNpb24tc2NyaXB0IExPQUQgdXNlIGR5bmFtaWNfbGlicmFy eV9wYXRoCgpDb21taXQgZjc3N2Q3NzM4NzggKGZpeCBmb3IgYnVnICMxODkyMCkgcmVzdHJpY3Rl ZCB0aGUgc2ltcGxlICIkbGliZGlyLyIKcHJlZml4IHN0cmlwcGluZyB0byBsb2FkX2V4dGVybmFs X2Z1bmN0aW9uKCkgc28gdGhhdCBhIHVzZXItaXNzdWVkCkxPQUQgJyRsaWJkaXIvZm9vJyB3b3Vs ZCBrZWVwIHRoZSBsaXRlcmFsICIkbGliZGlyLyIgcHJlZml4IGFuZCBub3QKY29uc3VsdCBkeW5h bWljX2xpYnJhcnlfcGF0aC4KCkEgc2lkZSBlZmZlY3QgaXMgdGhhdCBhIExPQUQgJyRsaWJkaXIv Zm9vJyBleGVjdXRlZCAqaW5zaWRlKiBhbgpleHRlbnNpb24gc2NyaXB0IGFsc28ga2VlcHMgdGhl IGxpdGVyYWwgcHJlZml4LCBzbyBhIGhhcmRjb2RlZAoiJGxpYmRpci8iIGxpYnJhcnkgcmVmZXJl bmNlIGluIGFuIGV4dGVuc2lvbidzIFNRTCBzY3JpcHQgY2FuIG5vCmxvbmdlciBiZSByZXNvbHZl ZCB0aHJvdWdoIGR5bmFtaWNfbGlicmFyeV9wYXRoLiAgVGhpcyBicmVha3MKZXh0ZW5zaW9ucyBp bnN0YWxsZWQgdmlhIGV4dGVuc2lvbl9jb250cm9sX3BhdGggLwpkeW5hbWljX2xpYnJhcnlfcGF0 aCAoZm9yIGV4YW1wbGUgUG9zdEdJUywgd2hvc2UgdXBncmFkZSBzY3JpcHRzIGRvCkxPQUQgJyRs aWJkaXIvcG9zdGdpcy0zJykuCgpBIExPQUQgcnVubmluZyBpbnNpZGUgYW4gZXh0ZW5zaW9uIHNj cmlwdCBzaG91bGQgYmVoYXZlIGxpa2UgdGhlCmV4dGVuc2lvbidzIGZ1bmN0aW9uIGxvYWRzOiBz dHJpcCB0aGUgc2ltcGxlICIkbGliZGlyLyIgcHJlZml4IGFuZApsZXQgZHluYW1pY19saWJyYXJ5 X3BhdGggYmUgY29uc3VsdGVkLiAgQSBMT0FEIGlzc3VlZCBkaXJlY3RseSBieSBhCnVzZXIgc2hv dWxkIGtlZXAgdGhlIGxpdGVyYWwgcHJlZml4LiAgVGhlIHR3byBhcmUgZGlzdGluZ3Vpc2hlZCBi eQpjcmVhdGluZ19leHRlbnNpb24uCgpGYWN0b3IgdGhlIGV4aXN0aW5nIHByZWZpeCBzdHJpcHBp bmcgaW50byBhIHNtYWxsIGhlbHBlciBhbmQgdXNlIGl0CmZyb20gbG9hZF9leHRlcm5hbF9mdW5j dGlvbigpIHVuY2hhbmdlZCBhbmQgZnJvbSBsb2FkX2ZpbGUoKSBvbmx5CndoaWxlIGFuIGV4dGVu c2lvbiBzY3JpcHQgaXMgYmVpbmcgZXhlY3V0ZWQuCgpSZXBvcnRlZC1ieTogR2FicmllbGUgQmFy dG9saW5pCkRpc2N1c3Npb246IGh0dHBzOi8vcG9zdGdyLmVzL20vMTk1MDYtOTQ3OGYzMDEyZWNj MjMyOEBwb3N0Z3Jlc3FsLm9yZwotLS0KIHNyYy9iYWNrZW5kL3V0aWxzL2ZtZ3IvZGZtZ3IuYyB8 IDM4ICsrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAy NSBpbnNlcnRpb25zKCspLCAxMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvYmFja2Vu ZC91dGlscy9mbWdyL2RmbWdyLmMgYi9zcmMvYmFja2VuZC91dGlscy9mbWdyL2RmbWdyLmMKaW5k ZXggZTYzNmNjODFjZjguLjE0YjZlNWI1YzRjIDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC91dGls cy9mbWdyL2RmbWdyLmMKKysrIGIvc3JjL2JhY2tlbmQvdXRpbHMvZm1nci9kZm1nci5jCkBAIC0y MCw2ICsyMCw3IEBACiAjaW5jbHVkZSA8ZGxmY24uaD4KICNlbmRpZgkJCQkJCQkvKiAhV0lOMzIg Ki8KIAorI2luY2x1ZGUgImNvbW1hbmRzL2V4dGVuc2lvbi5oIgogI2luY2x1ZGUgImZtZ3IuaCIK ICNpbmNsdWRlICJsaWIvc3RyaW5naW5mby5oIgogI2luY2x1ZGUgIm1pc2NhZG1pbi5oIgpAQCAt NzEsNiArNzIsNyBAQCBjaGFyCSAgICpEeW5hbWljX2xpYnJhcnlfcGF0aDsKIHN0YXRpYyB2b2lk ICppbnRlcm5hbF9sb2FkX2xpYnJhcnkoY29uc3QgY2hhciAqbGlibmFtZSk7CiBwZ19ub3JldHVy biBzdGF0aWMgdm9pZCBpbmNvbXBhdGlibGVfbW9kdWxlX2Vycm9yKGNvbnN0IGNoYXIgKmxpYm5h bWUsCiAJCQkJCQkJCQkJCQkgIGNvbnN0IFBnX2FiaV92YWx1ZXMgKm1vZHVsZV9tYWdpY19kYXRh KTsKK3N0YXRpYyBjb25zdCBjaGFyICpzdHJpcF9saWJkaXJfcHJlZml4KGNvbnN0IGNoYXIgKmZp bGVuYW1lKTsKIHN0YXRpYyBjaGFyICpleHBhbmRfZHluYW1pY19saWJyYXJ5X25hbWUoY29uc3Qg Y2hhciAqbmFtZSk7CiBzdGF0aWMgdm9pZCBjaGVja19yZXN0cmljdGVkX2xpYnJhcnlfbmFtZShj b25zdCBjaGFyICpuYW1lKTsKIApAQCAtOTksMjAgKzEwMSw3IEBAIGxvYWRfZXh0ZXJuYWxfZnVu Y3Rpb24oY29uc3QgY2hhciAqZmlsZW5hbWUsIGNvbnN0IGNoYXIgKmZ1bmNuYW1lLAogCXZvaWQJ ICAgKmxpYl9oYW5kbGU7CiAJdm9pZAkgICAqcmV0dmFsOwogCi0JLyoKLQkgKiBGb3IgZXh0ZW5z aW9ucyB3aXRoIGhhcmRjb2RlZCAnJGxpYmRpci8nIGxpYnJhcnkgbmFtZXMsIHdlIHN0cmlwIHRo ZQotCSAqIHByZWZpeCB0byBhbGxvdyB0aGUgbGlicmFyeSBzZWFyY2ggcGF0aCB0byBiZSB1c2Vk LiBUaGlzIGlzIGRvbmUgb25seQotCSAqIGZvciBzaW1wbGUgbmFtZXMgKGUuZy4sICIkbGliZGly L2ZvbyIpLCBub3QgZm9yIG5lc3RlZCBwYXRocyAoZS5nLiwKLQkgKiAiJGxpYmRpci9mb28vYmFy IikuCi0JICoKLQkgKiBGb3IgbmVzdGVkIHBhdGhzLCAnZXhwYW5kX2R5bmFtaWNfbGlicmFyeV9u YW1lJyBkaXJlY3RseSBleHBhbmRzIHRoZQotCSAqICckbGliZGlyJyBtYWNybywgc28gd2UgbGVh dmUgdGhlbSB1bnRvdWNoZWQuCi0JICovCi0JaWYgKHN0cm5jbXAoZmlsZW5hbWUsICIkbGliZGly LyIsIDgpID09IDApCi0JewotCQlpZiAoZmlyc3RfZGlyX3NlcGFyYXRvcihmaWxlbmFtZSArIDgp ID09IE5VTEwpCi0JCQlmaWxlbmFtZSArPSA4OwotCX0KKwlmaWxlbmFtZSA9IHN0cmlwX2xpYmRp cl9wcmVmaXgoZmlsZW5hbWUpOwogCiAJLyogRXhwYW5kIHRoZSBwb3NzaWJseS1hYmJyZXZpYXRl ZCBmaWxlbmFtZSB0byBhbiBleGFjdCBwYXRoIG5hbWUgKi8KIAlmdWxsbmFtZSA9IGV4cGFuZF9k eW5hbWljX2xpYnJhcnlfbmFtZShmaWxlbmFtZSk7CkBAIC0xNTAsNiArMTM5LDkgQEAgbG9hZF9m aWxlKGNvbnN0IGNoYXIgKmZpbGVuYW1lLCBib29sIHJlc3RyaWN0ZWQpCiB7CiAJY2hhcgkgICAq ZnVsbG5hbWU7CiAKKwlpZiAoY3JlYXRpbmdfZXh0ZW5zaW9uKQorCQlmaWxlbmFtZSA9IHN0cmlw X2xpYmRpcl9wcmVmaXgoZmlsZW5hbWUpOworCiAJLyogQXBwbHkgc2VjdXJpdHkgcmVzdHJpY3Rp b24gaWYgcmVxdWVzdGVkICovCiAJaWYgKHJlc3RyaWN0ZWQpCiAJCWNoZWNrX3Jlc3RyaWN0ZWRf bGlicmFyeV9uYW1lKGZpbGVuYW1lKTsKQEAgLTMwOSw2ICszMDEsMjQgQEAgaW50ZXJuYWxfbG9h ZF9saWJyYXJ5KGNvbnN0IGNoYXIgKmxpYm5hbWUpCiAJcmV0dXJuIGZpbGVfc2Nhbm5lci0+aGFu ZGxlOwogfQogCisvKgorICogRm9yIGV4dGVuc2lvbnMgd2l0aCBoYXJkY29kZWQgJyRsaWJkaXIv JyBsaWJyYXJ5IG5hbWVzLCBzdHJpcCB0aGUgcHJlZml4IHRvCisgKiBhbGxvdyB0aGUgbGlicmFy eSBzZWFyY2ggcGF0aCB0byBiZSB1c2VkLiBUaGlzIGlzIGRvbmUgb25seSBmb3Igc2ltcGxlIG5h bWVzCisgKiAoZS5nLiwgIiRsaWJkaXIvZm9vIiksIG5vdCBmb3IgbmVzdGVkIHBhdGhzIChlLmcu LCAiJGxpYmRpci9mb28vYmFyIikuCisgKgorICogRm9yIG5lc3RlZCBwYXRocywgZXhwYW5kX2R5 bmFtaWNfbGlicmFyeV9uYW1lKCkgZGlyZWN0bHkgZXhwYW5kcyB0aGUKKyAqICckbGliZGlyJyBt YWNybywgc28gbGVhdmUgdGhlbSB1bnRvdWNoZWQuCisgKi8KK3N0YXRpYyBjb25zdCBjaGFyICoK K3N0cmlwX2xpYmRpcl9wcmVmaXgoY29uc3QgY2hhciAqZmlsZW5hbWUpCit7CisJaWYgKHN0cm5j bXAoZmlsZW5hbWUsICIkbGliZGlyLyIsIDgpID09IDAgJiYKKwkJZmlyc3RfZGlyX3NlcGFyYXRv cihmaWxlbmFtZSArIDgpID09IE5VTEwpCisJCWZpbGVuYW1lICs9IDg7CisKKwlyZXR1cm4gZmls ZW5hbWU7Cit9CisKIC8qCiAgKiBSZXBvcnQgYSBzdWl0YWJsZSBlcnJvciBmb3IgYW4gaW5jb21w YXRpYmxlIG1hZ2ljIGJsb2NrLgogICovCi0tIAoyLjQzLjAKCmJhc2UtY29tbWl0OiA3NTk4YjUz ODNiMTZhNTYyYmQ3ZTc3MzJlZGE3ZDc4M2IzNGY0NjE1Cg== --000000000000160f5f06537a14fd--