On Mon, Nov 16, 2015 at 10:53 PM, Michael Paquier wrote: > Reviving an old thread for a patch still registered in this commit > fest to make the arguing move on. > > Supporting multiple verifiers for a single role has IMO clear advantages: > - help transition to new protocols and decommission of old protocols > without the need to create alternative roles in the backend when > switching from one or the other. > - move on to a more complex password aging system. The patch currently > submitted allows only one verifier per type and per role so this is > not a complete system. Still, the new catalog table pg_auth_verifiers > could be later easily extended based on other aging properties that we > consider adapted to reach this goal. > > There are clear concerns about protocol aging and how to facilitate > the life of users to switch to a new system. Hence, I think that the > patch could include the following: > - A compatibility GUC allowed_password_verifiers defaulting to a list > of verifier protocols that we think are safe. This would be added in > the patch adding infrastructure for multiple verifiers, with default > to md5. In the patch adding SCRAM, the value of this parameter is > changed to md5,scram. If a user create a password verifier with a > protocol not listed in this parameter we return to him a WARNING. > ERROR may be too much but opinions are welcome. > - A superuser cleanup function for pg_auth_verifiers aimed at being > used by pg_upgrade to do needed cleanup of this catalog based on the > previous GUC to remove outdated verifiers. Optionally, we could have > an argument for a list of protocols to clean up. > Using both things we could leverage the upgrade experience and > transition between systems. Say even if at some point we decide to > decommission SCRAM we could reuse the same infrastructure to move on > to a new major version. > > Thoughts?
I am going to mark this patch as returned with feedback because of a visible lack of interest. It would be nice if I could get some feedback about the suggestions above to help move on for (why not) a patch aiming for January's CF. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
