Message-ID: <3bc9ce78-054f-497c-8402-1cfda0bbc020@dunslane.net>
Date: Wed, 31 Jul 2024 09:38:16 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: can we mark upper/lower/textlike functions leakproof?
To: Joe Conway <mail@joeconway.com>, David Rowley <dgrowleyml@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <fa7903f6-b050-4c62-aa52-6f6d5d345770@dunslane.net>
 <CAApHDvr36T+9XZYTRkHkGm82Wo5YY6wXwkRDceu2-cyGEvHzjw@mail.gmail.com>
 <50d3a76e-afaa-44ed-aef5-6fb7f23cccab@dunslane.net>
 <5bef8bb0-7a50-4bcf-b052-2a12c3cda0f5@joeconway.com>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
Autocrypt: addr=andrew@dunslane.net; keydata=
 xsBNBE7KWFkBCAClridxur2AIc7eW2AR7izbfp3EnNefie2HbLF0izW5Ik5UjX2HBXBx4syI
 gY6b0ugohXrr274+baoAlvSbq6cAoQuEVrk5IZFzt20b1Xkx65FwGSEj526yiKLocqkJceSq
 Xr9xcA5SGY+FZv441chh5SU92v4q6z+6LPpoHOh97ptAVXZYNTtU0LevyvD5lja0TzbvJm6C
 eFXitJfnm1pLEr0DGJCR/iUOl/N62Kh4855zZC7NHIjQHPOvV5Stz/l5ilDhvGVk+xkXFPys
 SjZoUr1rXhYLpiyi5sR0X9FHXT0KnGuz1F5ERO7ZTLSSQ6fJwPj6gOk9K+vvoKvoeql5ABEB
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAmwQTAQgARQIbAwIX
 gAIZAQULCQgHAgMiAgEGFQoJCAsCBBYCAwECHgcWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUC
 ZFlxxwUJGVGAbgAKCRCZ+n/LWfw7gXikB/9ZdcUy6CTBFIIuL/bVsc1eLEW/gJBjJBF6HxNY
 xgEkAgXAp4Lg4A5U+QB9GouFr7+GYxF0BU4hzoGhNPUWltxnHdMWP8nC/38LAqgMi8L/bbsm
 HW5YPBdWYaAZAPJQVfOAgjTbRUb26KSprpyrrJKW0ZmrZfjhNPcQ72jpWzoPLQqx2X6B0fru
 1jq+cBh8lb6r1mJTim1T3JIn+F/v5VpdQS+EL8xqsHkfzKjIPsW3CIXpkypSk6saA55Rkkbl
 26AW8ftPVB0Q6Lnn6FLt9CP0MGNixBQ55yq8r1K+nCBvCCjvQjM8RDm0UUum0WNl+ifQgTLO
 E8TWEnwVtkBf+3QWzsBNBE7KWFkBCADRnOM0FCzsYW6jtncg+dWIagjUZpvaClmqn/sJluLa
 Q3v1VXMQJzYs3eC1gh386W+XBwLRpDj3jzH81lX+p73Re3d3oJW7X+ffsxuzu5ZVdMUkqBYo
 nkAbKxr6gyJ12F/+JkUVzLcoTN+d/7YsQvUVi7NaKH8mJgjz112O4fUe3p9wfAaFa0RXHc5S
 GPzRTYRRlv/XZBIho4J2tkZOnteZJZ+GbxQVlINt6fd8P6al3MWOvpP/ExJPguEfjOsO6Njy
 xjo3WfpD4lHMOR/Oc3/8mScEF84rF2jXbsFgelWnbPWAvXY+pD0dXOFRkagGmC/viwBDqq5b
 5tk76kKmUbZxABEBAAHCwHwEGAEIACYCGwwWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUCZFlx
 5wUJGVGAjgAKCRCZ+n/LWfw7gf+iB/4g8CPY5jihf5r/8EsoIGe2H+dpVmpPF8YGBzTIvCz/
 fQoOq8AX/pE76QEuFnFZWfjw+wgBXgCVmkox2Eflkk6z4ND3pcwGZ6CfCxTQCDk/dij+2DQ4
 6bmDCy/sBgcbz9mTpoLC11HLoPae6YN9nBNQRZDcEFEu54OaVOqlIdbA6m+POIBCXZdHOFc0
 WoDTgxHRzC1jgQNidyd6tKqcsVJs0dzF0oKTmFFmUAqTdJO12LBuNA1rlqrR3EtpYk8B/wtS
 5dIMD7Q8hwQpL+4C6GNpb6ZKnPkLi47pDOLhz2qBrqN+rqUEsT3YnExYpzj5yOBi+FlmV1Hw
 49QYe1sn2ZPs
In-Reply-To: <5bef8bb0-7a50-4bcf-b052-2a12c3cda0f5@joeconway.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/3bc9ce78-054f-497c-8402-1cfda0bbc020%40dunslane.net>
Precedence: bulk


On 2024-07-31 We 9:14 AM, Joe Conway wrote:
> On 7/31/24 05:47, Andrew Dunstan wrote:
>> On 2024-07-30 Tu 6:51 PM, David Rowley wrote:
>>> On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan<andrew@dunslane.net> 
>>> wrote:
>>>> Fast forward to now. The customer has found no observable ill 
>>>> effects of
>>>> marking these functions leakproof. The would like to know if there is
>>>> any reason why we can't mark them leakproof, so that they don't 
>>>> have to
>>>> do this in every database of every cluster they use.
>>>>
>>>> Thoughts?
>>> According to [1], it's just not been done yet due to concerns about
>>> risk to reward ratios.  Nobody mentioned any reason why it couldn't
>>> be, but there were some fears that future code changes could yield new
>>> failure paths.
>>>
>>> David
>>>
>>> [1]https://postgr.es/m/02BDFCCF-BDBB-4658-9717-4D95F9A91561%40thebuild.com 
>>>
>>
>> Hmm, somehow I missed that thread in searching, and clearly I'd 
>> forgotten it.
>>
>> Still, I'm not terribly convinced by arguments along the lines you're 
>> suggesting. "Sufficient unto the day is the evil thereof." Maybe we 
>> need a test to make sure we don't make changes along those lines, 
>> although I have no idea what such a test would look like.
>
>
> I think I have expressed this opinion before (which was shot down), 
> and I will grant that it is hand-wavy, but I will give it another try.
>
> In my opinion, for this use case and others, it should be possible to 
> redact the values substituted into log messages based on some 
> criteria. One of those criteria could be "I am in a leakproof call 
> right now". In fact in a similar fashion, an extension ought to be 
> able to mutate the log message based on the entire string, e.g. when 
> "ALTER ROLE...PASSWORD..." is spotted I would like to be able to 
> redact everything after "PASSWORD".
>
> Yes it might render the error message unhelpful, but I know of users 
> that would accept that tradeoff in order to get better performance and 
> security on their production workloads. Or in some cases (e.g. 
> PASSWORD) just better security.
>
--
Andrew Dunstan
EDB: https://www.enterprisedb.com