From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PATCH: warn about, and deprecate, clear text passwords |
Date: | 2025-02-24 21:06:41 |
Message-ID: | CAMsGm5ePTEVkzreF957TT7L2RapyfJ=fPAw-OoZ7+JQbWTvXSw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 24 Feb 2025 at 15:47, Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:
This is perhaps a nitpick, but one issue with ERROR-ing for clear text
> passwords is that the default logging settings seem to send the statement
> to the logs, too. So, it might actually increase the likelihood of the
> password showing up in the logs. I'm not sure what else could be done, but
> I believe the conventional wisdom is that logs can contain sensitive
> information, so maybe it's okay... It still seems weird to me to try to
> help folks to avoid logging passwords by logging their passwords.
>
It is definitely ironic, but it’s non-routinely logging their proposed new
password which, due to the server settings, does not actually get set as
the new password, in order to prevent routinely logging their passwords.
What I mean is, after the error is thrown and the proposed password logged,
they need to re-try with a pre-encrypted password which will not be logged.
If they choose a new password, then the logged one is irrelevant, and even
if they don't, it's just one password rather than all the ones they change.
So on the whole I think this is good. And in any case I believe the
existing behaviour can still be had by configuration so we're not really
imposing anything on anybody.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2025-02-24 21:07:39 | Re: Statistics Import and Export |
Previous Message | Nathan Bossart | 2025-02-24 21:02:55 | Re: MAX_BACKENDS size (comment accuracy) |