Re: POC: Carefully exposing information without authentication

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Antonin Houska <ah(at)cybertec(dot)at>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: POC: Carefully exposing information without authentication
Date: 2026-09-16 23:50:59
Message-ID: CAOYmi+kfpag+SVDr+6yQgzkD0ws+UaamkG2bbpVQDr6AbeL-kg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 16, 2026 at 7:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> > To be honest, I am absolutely terrified by any feature which does any level of
> > work based on user input before authentication or authorization.
>
> Yeah. TBH, I can't see this ever getting committed.

I agree.

Greg, I think any design that mixes HTTP and the Postgres protocol on
the wire is probably doomed, because then we all get to be forever
vigilant against cross-protocol attacks. I have many, many, more
issues with the design as presented, but IMNSHO the core feature is a
nonstarter, so it doesn't make much sense to get into those details.

It seems to me that there's nothing wrong with running a separate
service that provides that information, which can then be tailored to
whatever security requirements (or not) are required.

--Jacob

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-09-17 01:07:51 Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start
Previous Message Michael Paquier 2026-09-16 23:50:34 Re: Support for 8-byte TOAST values, round two