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
