> Bear Giles <[EMAIL PROTECTED]> writes: > > 1) add SASL. This is a new standards-track protocol that is often > > described as "PAM" for network authentication. > > To me, "new standards-track protocol" translates as "pie in the sky". > When will there be tested, portable, BSD-license libraries that we > could *actually* use?
http://asg.web.cmu.edu/sasl/sasl-implementations.html > Unless you can make a credible case that using SASL would > allow us to rip out PAM, Kerberos, MD5, etc *now* (not "in a few releases > when everyone's switched to SASL"), I think this will end up just being > another one :-(. http://asg.web.cmu.edu/sasl/sasl-projects.html If it's being used in Sendmail, Cyrus IMAP and OpenLDAP, with preliminary work (sponsored by Carnegie Mellon University) in supporting it for CVS and LPRng and possibly SSH I think it's safe to say it's beyond "vaporware" at this point. The only reason I was waving my hands a bit is that I'm not sure if SASL 2.x is considered production-ready yet. We could support SASL 1.x, but if 2.x is coming out within 6-12 months then it may make more sense to target 2.x instead of releasing 1.x today, then switching to 2.x in the next release. If there's a concensus that we should proceed, I would also be the first to argue that we should contact CMU for assistance in the conversion. Hopefully they have enough experience with their cyrus package that we can really put this issue to bed. (Meanwhile PostgreSQL would get more free advertising as another major project using their SASL library.) > (It doesn't help any that PAM support was sold to us just one release > cycle back on the same grounds that it'd be the last authentication > method we'd need to add. I'm more than a tad wary now...) Umm... I don't know what to say. This is a common misunderstanding of PAM (and one reason I *really* hate those PAM Kerberos modules) but people keep repeating it. PAM was only designed for local use, but people keep trying to use it for network authentication even though us security freaks keep pointing out that using some of those modules on a network will leave your system wide open. In contrast SASL was designed from the start to work over an untrusted network. This isn't to say that PAM support is totally useless - it may be a clean way to handle the ongoing Kerberos principal -> pguser issue, but it's a nonstarter for authentication purposes unless you know you're on the Unix socket. > > 2) add ZLIB compression. > > Why do people keep wanting to reinvent SSH tunneling? One good reason is that secure sites will prohibit them. SSH tunnels require that clients have shell accounts on the remote system, and on a dedicated database server you may have no accounts other than the sysadmins who administer the box. I'm aware of the various tricks you can do - setting the shell to /bin/false, requiring RSA authentication and setting the no-tty flag in the 'known_keys' file, etc., but at the end of the day there are still extra shell accounts on that system. SSH tunnels are a good stopgap measure while you add true TLS/SSL support, but they can't be considered a replacement for that support. Bear ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
