Re: Password leakage avoidance

On 12/27/23 16:09, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> On 12/27/23 15:39, Peter Eisentraut wrote:
>>> On 23.12.23 16:13, Joe Conway wrote:
>>>> The attached patch set moves the guts of \password from psql into the
>>>> libpq client side -- PQchangePassword() (patch 0001).
>
>>> I don't follow how you get from the problem statement to this solution.
>>> This proposal doesn't avoid password leakage, does it?
>>> It just provides a different way to phrase the existing solution.
>
>> Yes, a fully built one that is convenient to use, and does not ask
>> everyone to roll their own.
>
> It's convenient for users of libpq, I guess, but it doesn't help
> anyone not writing C code directly atop libpq. If this is the
> way forward then we need to also press JDBC and other client
> libraries to implement comparable functionality. That's within
> the realm of sanity surely, and having a well-thought-through
> reference implementation in libpq would help those authors.
> So I don't think this is a strike against the patch; but the answer
> to Peter's question has to be that this is just part of the solution.

As mentioned downthread by Dave Cramer, JDBC is already onboard.

And as Jonathan said in an adjacent part of the thread:
> This should generally helpful, as it allows libpq-based drivers to
> adopt this method and provide a safer mechanism for setting/changing
> passwords! (which we should also promote once availbale).

Which is definitely something I have had in mind all along.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com