Joshua Brindle <joshua.brin...@crunchydata.com> writes: > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas <robertmh...@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
