public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jonathan S. Katz <[email protected]>
To: Peter Eisentraut <[email protected]>
To: Stephen Frost <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: samay sharma <[email protected]>
Cc: [email protected]
Subject: Re: Proposal: Support custom authentication methods using hooks
Date: Wed, 2 Mar 2022 09:16:10 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 3/2/22 3:24 AM, Peter Eisentraut wrote:
> On 01.03.22 22:17, Jonathan S. Katz wrote:
>> If you're moving to a newer version of PostgreSQL, you likely have to 
>> update your connection drivers anyway (rebuilt against new libpq, 
>> supporting any changes in the protocol, etc). I would prefer more data 
>> to support that argument, but this is generally what you need to do.
>>
>> However, we may need to step towards it. We took one step last release 
>> with defaulting to SCRAM. Perhaps this release we add a warning for 
>> anything using md5 auth that "this will be removed in a future 
>> release." (or specifically v16). We should also indicate in the docs 
>> that md5 is deprecated and will be removed.
> 
> I find that a lot of people are still purposely using md5.  Removing it 
> now or in a year would be quite a disruption.

What are the reasons they are still purposely using it? The ones I have 
seen/heard are:

- Using an older driver
- On a pre-v10 PG
- Unaware of SCRAM

What I'm proposing above is to start the process of deprecating it as an 
auth method, which also allows to continue the education efforts to 
upgrae. Does that make sense?

> It's also worth considering that keeping the code equipped to handle 
> different kinds of password hashing would help it stay in shape if we 
> ever need to add support for the next SHA after 256 or whatever.

I think it's fine to keep the hashing code. The end goal is to remove 
the md5 authentication mechanism.

Thanks,

Jonathan




Attachments:

  [application/pgp-signature] OpenPGP_signature (840B, ../[email protected]/2-OpenPGP_signature)
  download

view thread (24+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Proposal: Support custom authentication methods using hooks
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox