From: | "Henry B (Hank) Hotz, CISSP" <hbhotz(at)oxy(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Hotz Henry B(dot)" <hbhotz(at)oxy(dot)edu> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Subject: | Re: reducing our reliance on MD5 |
Date: | 2015-02-14 18:12:03 |
Message-ID: | 790CA760-CD8C-4E74-AE60-05D1BCDFC4E7@oxy.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. hbhotz(at)oxy(dot)edu
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-02-14 19:10:53 | Re: "multiple backends attempting to wait for pincount 1" |
Previous Message | Andres Freund | 2015-02-14 17:56:03 | Re: "multiple backends attempting to wait for pincount 1" |