SASL was done by many of the same people who did GSSAPI. It's main practical advantages are that it supports password-based mechanisms (in addition to GSSAPI/krb5), and that it’s more explicitly pluggable than GSSAPI is.
The password mechanism is simple enough that it's frequently implemented without a general library in e.g. older Jabber clients. We could likewise provide that as a configure fallback if availability of client libraries turns out to be a problem. Cyrus SASL is bundled with a saslauthd and other utilities that handle the on-disk storage of hashed passwords. SASLauthd can be configured to use PAM, Kerberos 5, MySQL, custom plugin, or local BDB files for password verification/storage. (Instead of our own, we can provide someone else’s gun to shoot yourself with! ;-)) For myself, I think getting rid of MD5 is a low priority. If its replaced with SASL, then that has the advantage (?) of replacing GSSAPI as well, so the number of user options increases while the number of mechanisms in PG itself decreases. Personal email. hbh...@oxy.edu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
