Re: lower() and unaccent() not leakproof

On 26.08.21 10:40, Daniel Gustafsson wrote:
>> On 26 Aug 2021, at 09:58, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>>
>> On 26.08.21 06:52, David G. Johnston wrote:
>>> On Wednesday, August 25, 2021, Christophe Pettus <xof(at)thebuild(dot)com <mailto:xof(at)thebuild(dot)com>> wrote:
>>> lower() and unaccent() (and most string functions) are not marked as
>>> leakproof. Is this due to possible locale / character encoding
>>> errors they might encounter?
>>> I think you are partially correct. Its due to the fact that error messages, regardless of the root cause, result in the printing of the input value in the error message as context, thus exists a leak via a violation of “ It reveals no information about its arguments other than by its return value. ”
>>
>> I think if you trace the code, you might find that lower() and upper() can't really leak anything. It might be worth taking a careful look and possibly lifting this restriction.
>
> Wouldn’t the difference in possible error messages in upper/lower be able to
> leak whether the input is ascii or wide chars, and/or the collation?

Yeah, but there aren't any error messages that relate to the argument
string, if you look through the code. There isn't any "could not find
lower case equivalent of %s" or anything like that. Once you have found
the right collation and locale and server encoding and have allocated
some memory, the conversion always succeeds.

The collation is not secret, it's determined by parse analysis.