MIME-Version: 1.0
References: <1791665551.452444.1761209220211.ref@mail.yahoo.com>
 <CAJ7c6TOramr1UTLcyB128LWMqita1Y7=arq3KHaU=qikf5yKOQ@mail.gmail.com>
 <18022523-0F8F-4C07-AFF5-57DC9086D78E@yandex-team.ru>
 <1895971769.8343.1761240853939@mail.yahoo.com>
 <CAD21AoCxy_3VW2_z5Rxc-tFsuqeyGsA-F_kD-tx6XXBC56nTCg@mail.gmail.com>
 <574624399.175025.1761290201491@mail.yahoo.com>
 <CAD21AoAXQcZ2mMkxX6NPdFpdC-D3AhE--qyH9Se3XTrDX6x-bg@mail.gmail.com>
 <953203149.383019.1761345585325@mail.yahoo.com>
 <CAD21AoCzEDdwpyPwA0d-QmCRe5rMz3m160SJgxMwKke85e8n0w@mail.gmail.com>
 <6F76FA61-E2DC-44EF-9504-889D9BDB4EBD@yandex-team.ru>
 <CAD21AoCKvYCccndY4CRcwk1bOuWxJionOidEtKQWoJTqS7wL1g@mail.gmail.com>
 <1154454839.957923.1761604611424@mail.yahoo.com>
 <CAGECzQTb9pg2Qw0XmOEKaJivLJ8kdGq3Cq38OqSgwiFVD=9f8A@mail.gmail.com>
 <87ldkv8cog.fsf@wibble.ilmari.org> <87ikfz7zcu.fsf@wibble.ilmari.org>
 <CAD21AoCf-0LdE=Js3ViXmKfSATJOjSNym1+80O+=-Y3X6LDMyA@mail.gmail.com>
 <9CB824CC-70DC-4165-AC6A-9664F47209EE@yandex-team.ru>
 <aa24964a-f0d7-435e-9254-bb69823948d6@gmail.com>
 <CAJ7c6TNCGT2eZ8JttAZKUhVv3jJFTHvjFw6typzSGkM5_vePow@mail.gmail.com>
 <CAJ7c6TMZOvVcbEZ-KH8e4mDuQ6ZTfgV-BJoLX_aTd1MtjScyqA@mail.gmail.com>
 <CAD21AoCcikUgU5coyvM7PLJg5M-75LzQhm-Uxmqn_7M=DHkj+w@mail.gmail.com>
 <CAJ7c6TPu7NGrSj-V2-ns0GTNGx9cmoKQgzt-p2MpJepiGjQnYw@mail.gmail.com>
 <CAD21AoC2Ooy=W=4YjQ_GO5nEYZ2tsn43=TkLf7ysE-96ygohKg@mail.gmail.com>
 <CAJ7c6TOJ-aJh=dnPSwtzWsHnANi=SVZQ3bYuZLtS2w8xxVngnQ@mail.gmail.com>
In-Reply-To: 
 <CAJ7c6TOJ-aJh=dnPSwtzWsHnANi=SVZQ3bYuZLtS2w8xxVngnQ@mail.gmail.com>
From: Chengxi Sun <chengxisun92@gmail.com>
Date: Thu, 19 Mar 2026 20:12:17 +0800
Message-ID: 
 <CAMvSjCRxFgKC3JfOMSr358zGu166niRY2UqaTS_=oQcyiBArmQ@mail.gmail.com>
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in
 functions
To: Aleksander Alekseev <aleksander@tigerdata.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
	Andrey Borodin <x4mmm@yandex-team.ru>,
 =?UTF-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org>
Content-Type: multipart/alternative; boundary="000000000000869261064d5f7b68"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMvSjCRxFgKC3JfOMSr358zGu166niRY2UqaTS_%3DoQcyiBArmQ%40mail.gmail.com>
Precedence: bulk

--000000000000869261064d5f7b68
Content-Type: text/plain; charset="UTF-8"

I have a concern with base32hex_decode(). It only checks where the first =
appears,
but it does not validate the final group length or the required amount of
padding.
Because of that, some invalid inputs are accepted silently.

For example:

postgres=# SET bytea_output = hex;
SET
postgres=# SELECT '0' AS input, decode('0', 'base32hex');
 input | decode
-------+--------
 0     | \x
(1 row)

postgres=# SELECT '000' AS input , decode('000', 'base32hex');
 input | decode
-------+--------
 000   | \x00
(1 row)

postgres=# SELECT '24=' as input , decode('24=', 'base32hex');
 input | decode
-------+--------
 24=   | \x11
(1 row)

These looks good, but if we verify that with python:
% python3 - <<'PY'
import base64

tests = [
    "24",
    "24======",
    "0",
    "000",
    "24=",
]

for s in tests:
    try:
        out = base64.b32hexdecode(s, casefold=True)
        print(f"{s!r} -> OK {out.hex()}")
    except Exception as e:
        print(f"{s!r} -> ERROR: {e}")
PY

The outputs are:
'24' -> ERROR: Incorrect padding
'24======' -> OK 11
'0' -> ERROR: Incorrect padding
'000' -> ERROR: Incorrect padding
'24=' -> ERROR: Incorrect padding

I might be missing some context here, so I wanted to ask: is this behavior
intentional,
or would it make sense to enforce stricter validation for Base32hex input?

Best regards,

Chengxi Sun

--000000000000869261064d5f7b68
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quot=
e">I have a concern with base32hex_decode(). It only checks where the first=
 =3D appears,=C2=A0</div><span style=3D"color:inherit"><div class=3D"gmail_=
quote">but it does not validate the final group length or the required amou=
nt of padding.=C2=A0</div></span><div class=3D"gmail_quote"><span style=3D"=
color:inherit">Because of that, some invalid inputs are accepted silently.<=
br><br>For example:<br><br></span>postgres=3D# SET bytea_output =3D hex;<br=
>SET<br>postgres=3D# SELECT &#39;0&#39; AS input, decode(&#39;0&#39;, &#39;=
base32hex&#39;);<span style=3D"color:inherit"><br>=C2=A0input | decode<br>-=
------+--------<br>=C2=A00 =C2=A0 =C2=A0 | \x<br>(1 row)<br><br></span>post=
gres=3D# SELECT &#39;000&#39; AS input , decode(&#39;000&#39;, &#39;base32h=
ex&#39;);<br>=C2=A0input | decode<br>-------+--------<br>=C2=A0000 =C2=A0 |=
 \x00<br>(1 row)<br><br>postgres=3D# SELECT &#39;24=3D&#39; as input , deco=
de(&#39;24=3D&#39;, &#39;base32hex&#39;);<br>=C2=A0input | decode<span styl=
e=3D"color:inherit"><br>-------+--------<br>=C2=A024=3D =C2=A0 | \x11<br>(1=
 row)<br><br></span>These looks good, but if we verify that with python:<sp=
an style=3D"color:inherit"><br>% python3 - &lt;&lt;&#39;PY&#39;<br>import b=
ase64<br><br>tests =3D [<br>=C2=A0 =C2=A0 &quot;24&quot;,<br>=C2=A0 =C2=A0 =
&quot;24=3D=3D=3D=3D=3D=3D&quot;,<br>=C2=A0 =C2=A0 &quot;0&quot;,<br>=C2=A0=
 =C2=A0 &quot;000&quot;,<br>=C2=A0 =C2=A0 &quot;24=3D&quot;,<br>]<br><br>fo=
r s in tests:<br>=C2=A0 =C2=A0 try:<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 out =3D =
base64.b32hexdecode(s, casefold=3DTrue)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 prin=
t(f&quot;{s!r} -&gt; OK {out.hex()}&quot;)<br>=C2=A0 =C2=A0 except Exceptio=
n as e:<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 print(f&quot;{s!r} -&gt; ERROR: {e}&=
quot;)<br>PY</span></div><div class=3D"gmail_quote"><br></div><div class=3D=
"gmail_quote">The outputs are:</div><span style=3D"color:inherit"><div clas=
s=3D"gmail_quote">&#39;24&#39; -&gt; ERROR: Incorrect padding<br>&#39;24=3D=
=3D=3D=3D=3D=3D&#39; -&gt; OK 11<br>&#39;0&#39; -&gt; ERROR: Incorrect padd=
ing<br>&#39;000&#39; -&gt; ERROR: Incorrect padding<br>&#39;24=3D&#39; -&gt=
; ERROR: Incorrect padding</div><div class=3D"gmail_quote"><br></div></span=
><div class=3D"gmail_quote">I might be missing some context here, so I want=
ed to ask: is this behavior intentional,=C2=A0</div><div class=3D"gmail_quo=
te">or would it make sense to enforce stricter validation for Base32hex inp=
ut?=C2=A0=C2=A0</div><div class=3D"gmail_quote"><br></div><div class=3D"gma=
il_quote">Best regards,</div><div class=3D"gmail_quote"><br></div><div clas=
s=3D"gmail_quote">Chengxi Sun</div></div>
</div>
</div>

--000000000000869261064d5f7b68--