Horton

Thread

Commits

  1. Mark uuid-to-bytea cast as leakproof.

  1. bytea(uuid) missing proleakproof?

    Chao Li <li.evan.chao@gmail.com> — 2026-06-22T03:59:48Z

    Hi,

While testing "[ba21f5bf8] Allow explicit casting between bytea and uuid", I noticed that the new proc bytea(uuid) is not marked as proleakproof, while the other functions in the group, bytea(int2), bytea(int4), and bytea(int8), are all marked as proleakproof.

Looking into the backend function uuid_bytea(), it just returns uuid_send(fcinfo). For a valid uuid datum, uuid_send() only copies the UUID value into a bytea result, so I don't see an input-dependent error path or other reason not to mark bytea(uuid) as proleakproof.

This matters for security barrier planning, because a qual using uuid::bytea is otherwise treated as leaky and cannot be pushed down. Attached is a tiny patch to fix that.

I didn't mark uuid_send() itself as proleakproof because none of send/receive functions are marked as proleakproof in pg_proc.dat.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  2. Re: bytea(uuid) missing proleakproof?

    Chao Li <li.evan.chao@gmail.com> — 2026-06-24T07:47:36Z

    
> On Jun 22, 2026, at 11:59, Chao Li <li.evan.chao@gmail.com> wrote:
> 
> Hi,
> 
> While testing "[ba21f5bf8] Allow explicit casting between bytea and uuid", I noticed that the new proc bytea(uuid) is not marked as proleakproof, while the other functions in the group, bytea(int2), bytea(int4), and bytea(int8), are all marked as proleakproof.
> 
> Looking into the backend function uuid_bytea(), it just returns uuid_send(fcinfo). For a valid uuid datum, uuid_send() only copies the UUID value into a bytea result, so I don't see an input-dependent error path or other reason not to mark bytea(uuid) as proleakproof.
> 
> This matters for security barrier planning, because a qual using uuid::bytea is otherwise treated as leaky and cannot be pushed down. Attached is a tiny patch to fix that.
> 
> I didn't mark uuid_send() itself as proleakproof because none of send/receive functions are marked as proleakproof in pg_proc.dat.
> 
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
> 
> 
> 
> 
> <v1-0001-Mark-uuid-to-bytea-cast-as-leakproof.patch>

I just added this to the v19 open item list. Please feel free to reject it if it’s not considered an issue.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  3. Re: bytea(uuid) missing proleakproof?

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-06-24T18:30:04Z

    Hi,

On Sun, Jun 21, 2026 at 9:00 PM Chao Li <li.evan.chao@gmail.com> wrote:
>
> Hi,
>
> While testing "[ba21f5bf8] Allow explicit casting between bytea and uuid", I noticed that the new proc bytea(uuid) is not marked as proleakproof, while the other functions in the group, bytea(int2), bytea(int4), and bytea(int8), are all marked as proleakproof.
>
> Looking into the backend function uuid_bytea(), it just returns uuid_send(fcinfo). For a valid uuid datum, uuid_send() only copies the UUID value into a bytea result, so I don't see an input-dependent error path or other reason not to mark bytea(uuid) as proleakproof.
>
> This matters for security barrier planning, because a qual using uuid::bytea is otherwise treated as leaky and cannot be pushed down. Attached is a tiny patch to fix that.
>
> I didn't mark uuid_send() itself as proleakproof because none of send/receive functions are marked as proleakproof in pg_proc.dat.

Thank you for the report.

I agree that we should mark bytea(uuid) (i.e., converting uuid ->
bytea) as leakproof but not the opposite direction.

The patch is simple and looks good to me. I'll push the patch, barring
any objections.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

  4. Re: bytea(uuid) missing proleakproof?

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-06-25T21:35:44Z

    On Wed, Jun 24, 2026 at 11:30 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> Hi,
>
> On Sun, Jun 21, 2026 at 9:00 PM Chao Li <li.evan.chao@gmail.com> wrote:
> >
> > Hi,
> >
> > While testing "[ba21f5bf8] Allow explicit casting between bytea and uuid", I noticed that the new proc bytea(uuid) is not marked as proleakproof, while the other functions in the group, bytea(int2), bytea(int4), and bytea(int8), are all marked as proleakproof.
> >
> > Looking into the backend function uuid_bytea(), it just returns uuid_send(fcinfo). For a valid uuid datum, uuid_send() only copies the UUID value into a bytea result, so I don't see an input-dependent error path or other reason not to mark bytea(uuid) as proleakproof.
> >
> > This matters for security barrier planning, because a qual using uuid::bytea is otherwise treated as leaky and cannot be pushed down. Attached is a tiny patch to fix that.
> >
> > I didn't mark uuid_send() itself as proleakproof because none of send/receive functions are marked as proleakproof in pg_proc.dat.
>
> Thank you for the report.
>
> I agree that we should mark bytea(uuid) (i.e., converting uuid ->
> bytea) as leakproof but not the opposite direction.
>
> The patch is simple and looks good to me. I'll push the patch, barring
> any objections.

Pushed, and resolved the open item.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

  5. Re: bytea(uuid) missing proleakproof?

    Chao Li <li.evan.chao@gmail.com> — 2026-06-25T22:17:08Z

    
> On Jun 26, 2026, at 05:35, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> 
> On Wed, Jun 24, 2026 at 11:30 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> 
>> Hi,
>> 
>> On Sun, Jun 21, 2026 at 9:00 PM Chao Li <li.evan.chao@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> While testing "[ba21f5bf8] Allow explicit casting between bytea and uuid", I noticed that the new proc bytea(uuid) is not marked as proleakproof, while the other functions in the group, bytea(int2), bytea(int4), and bytea(int8), are all marked as proleakproof.
>>> 
>>> Looking into the backend function uuid_bytea(), it just returns uuid_send(fcinfo). For a valid uuid datum, uuid_send() only copies the UUID value into a bytea result, so I don't see an input-dependent error path or other reason not to mark bytea(uuid) as proleakproof.
>>> 
>>> This matters for security barrier planning, because a qual using uuid::bytea is otherwise treated as leaky and cannot be pushed down. Attached is a tiny patch to fix that.
>>> 
>>> I didn't mark uuid_send() itself as proleakproof because none of send/receive functions are marked as proleakproof in pg_proc.dat.
>> 
>> Thank you for the report.
>> 
>> I agree that we should mark bytea(uuid) (i.e., converting uuid ->
>> bytea) as leakproof but not the opposite direction.
>> 
>> The patch is simple and looks good to me. I'll push the patch, barring
>> any objections.
> 
> Pushed, and resolved the open item.
> 
> Regards,
> 
> -- 
> Masahiko Sawada
> Amazon Web Services: https://aws.amazon.com

Thanks for taking care of this patch.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/