Joshua Brindle <joshua.brindle@crunchydata.com> writes:
> On Thu, Feb 28, 2019 at 9:12 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> So... you're just going to replace ALL error messages of any kind with
>> "ERROR: missing error text" when this option is enabled? That sounds
>> unusable. I mean if I'm reading it right this would get not only
>> messages from SQL-callable functions but also things like "deadlock
>> detected" and "could not read block %u in file %s" and "database is
>> not accepting commands to avoid wraparound data loss in database with
>> OID %u". You can't even shut it off conveniently, because the way
> This makes complete sense to me. The client side of a client/server
> protocol doesn't have any way to fix 'could not read block %u in file
> %s', the client doesn't need that kind of detailed information about a
> server, and in fact that information could be security sensitive.
I agree with Robert that this idea is a nonstarter. Not only is it
a complete disaster from a usability standpoint, but *it does not
fix the problem*. The mere fact that an error occurred, or didn't,
is already an information leak. Sure, you can only extract one bit
per query that way, but a slow leak is still a leak. See the Spectre
vulnerability for a pretty exact parallel.
The direction I think we're going to need to go in is to weaken our
standards for what we'll consider a leakproof function, and/or try
harder to make common WHERE-clause operators leakproof. The thread
over at
https://www.postgresql.org/message-id/flat/7DF52167-4379-4A1E-A957-90D774EBDF21%40winand.at
raises the question of why we don't expect that *all* indexable
operators are leakproof, at least with respect to the index column
contents. (Failing to distinguish which of the inputs can be
leaked seems like a pretty fundamental mistake in hindsight.
For instance, some opclasses can directly index regex operators,
and one would not wish to give up the ability for a regex operator
to complain about an invalid pattern. But it could be leakproof
with respect to the data side.)
regards, tom lane
