Hi, On 2022-03-18 00:45:49 -0400, Stephen Frost wrote: > > I also don’t think that I agree that it’s acceptable to only have the > > > ability to extend the authentication on the server side as that implies a > > > whole bunch of client-side work that goes above and beyond just > > > implementing an authentication system if it’s not possible to leverage > > > libpq (which nearly all languages out there use..). Not addressing that > > > side of it also makes me concerned that whatever we do here won’t be > > > right/enough/etc. > > > > You're skipping over my point of everything that can be made to use > > SASL-SCRAM-256 just working with the existing libpq? Again?
> The plan is to make scram pluggable on the client side? That isn’t what’s > been proposed here that I’ve seen. Libpq and many other drivers already speaks SASL-SCRAM-256. If you're implementing an authentication method that wants to store secrets outside of postgres (centrally in another postgres instance, ldap, mysql or whatnot) you don't need to make scram pluggable client-side. From the perspective of the client it'd look *exactly* like the normal auth flow with the server. What's proposed here is not really about adding new authentication protocols between FE/BE (although some *limited* forms of that might be possible). It's primarily about using the existing FE/BE authentication exchanges (AUTH_REQ_{PASSWORD,SASL*,...}) to validate against something other than the builtin pg_authid.rolpassword. Because drivers already know those authentication exchanges, it doesn't need to learn new tricks. As I said in https://www.postgresql.org/message-id/20220318032520.t2bcwrnterg6lq6g%40alap3.anarazel.de when describing the above, that's not enough to implement every desireable authentication method - but there's real use-cases where using the existing SASL-SCRAM-256 is sufficient. > I also wasn’t aware that we felt that it’s acceptable to just ignore other > committers. I'm not talking about going ahead and committing. Just not continuing discussing this topci and spending my time more fruitfully on something else. Greetings, Andres Freund