Re: Add a warning message when using unencrypted passwords

On 04/02/2025 19:14, Guillaume Lelarge wrote: On 04/02/2025 17:59, Tom Lane wrote: Guillaume Lelarge writes: v2 is attached. This seems pretty much entirely useless to me.  The password has already been leaked to the log (*and* the network, if session is unencrypted), so what's the point of

Re: Add a warning message when using unencrypted passwords

On 04/02/2025 17:59, Tom Lane wrote: Guillaume Lelarge writes: v2 is attached. This seems pretty much entirely useless to me. The password has already been leaked to the log (*and* the network, if session is unencrypted), so what's the point of a warning? And as already noted, this ignores s

Re: Add a warning message when using unencrypted passwords

Guillaume Lelarge writes: > v2 is attached. This seems pretty much entirely useless to me. The password has already been leaked to the log (*and* the network, if session is unencrypted), so what's the point of a warning? And as already noted, this ignores several other hazards of the same sort,

Re: Add a warning message when using unencrypted passwords

On 09/12/2024 15:58, Guillaume Lelarge wrote: Hi, Le lun. 9 déc. 2024 à 14:40, Daniel Gustafsson > a écrit : > On 9 Dec 2024, at 14:26, Greg Sabino Mullane mailto:htamf...@gmail.com>> wrote: > -1 to throwing an ERROR - that's not really an error, and not our

Re: Add a warning message when using unencrypted passwords

On Sat, Dec 07, 2024 at 03:39:55PM +0100, Guillaume Lelarge wrote: > I thought about it, and tried to write a patch. I've mostly copied the > "Deprecate MD5 passwords" patch/commit from Nathan Bossart. My patch works > on current HEAD. Documentation and tests are dealt with. I've been thinking abo

Re: Add a warning message when using unencrypted passwords

Hi, Le lun. 9 déc. 2024 à 14:40, Daniel Gustafsson a écrit : > > On 9 Dec 2024, at 14:26, Greg Sabino Mullane wrote: > > > -1 to throwing an ERROR - that's not really an error, and not our call > to make, so a WARNING is sufficient. > > Agreed, regardless of how bad it's considered, it's not an

Re: Add a warning message when using unencrypted passwords

> On 9 Dec 2024, at 14:26, Greg Sabino Mullane wrote: > -1 to throwing an ERROR - that's not really an error, and not our call to > make, so a WARNING is sufficient. Agreed, regardless of how bad it's considered, it's not an error. There are many ways sensitive data can end up in the logs and

Re: Add a warning message when using unencrypted passwords

Overall +1 to the idea of a warning. Regarding warning vs error, I agree that a WARNING is probably the right > choice generally. But I think that Divya is correct: When > log_statement = 'all', an error should be thrown instead. First, it should be for 'all' AND 'ddl'. And obviously glossing ov

Re: Add a warning message when using unencrypted passwords

On Sat, 7 Dec 2024 at 15:40, Guillaume Lelarge wrote: > > Whenever log_statement is set to all (which I understand should be done for > > a short period of time for troubleshooting purposes only), if we change the > > password for a user, or create a new user, the passwords would be logged in >

Re: Add a warning message when using unencrypted passwords

On 7/12/2024 21:39, Guillaume Lelarge wrote: I'm interested in any comments about this. I didn't create a commitfest entry yet, I'm mostly waiting on your comments. My first impression is that such a GUC may be generalised - something like a 'security_warnings' parameter. Also, you can check the

Add a warning message when using unencrypted passwords

Hello, We've got a long tradition of telling people not to use unencrypted passwords in CREATE ROLE and ALTER ROLE because the queries may be logged. We try to encourage them to use \password in psql, and related techniques on other tools. Users usually want us to stop logging passwords, but this