That was my first attempt to use git send-email; I wanted to have a little extra explanation than the commit message, but that didn't happen.
In any case, this allows pam_userdb.so to use all the new crypt formats. It's no longer limited to DES-crypted passwords and a measly 12 bits of entropy on the salt. crypt will detect which password-hashing algorithm was used to store the password via the salt (either the obsolete DES or MD5, or tbcrypt or the new SHA256 and SHA512 based formats) and hash accordingly. Without this patch, pam_userdb is out of the question for pretty much any purpose.
I started playing with pam via google-authenticate yesterday, and one thing I've wanted for a while is the ability to maintain a separate database of passwords to authenticate the sudo command. The reason being, I like to use a convenient password to get to root, but not allow ssh logins using said password. (or preferably, any password at all...) However disabling password logins via ssh is not always an option on servers that other admins access as well. And some of the servers have older software stacks, where sshd can't disable passwords on a per-user basis. So I was hoping there was a nice simple way to set a sudo password with a minimal (preferably no) requirement for additional software or software upgrades, and lock my regular password.
I pretty quickly found pam_userdb, which seemed exactly what I needed, but try as I might, I just couldn't get crypted passwords working, so I eventually looked at the source and found this problem. The fix appears to be working just fine on my laptop.
One thing I'm not exactly clear on is how crypt() deals with the boundary conditions on the salt, and couldn't find anything in the documentation in this regard. However, the worst that could happen with a runaway boundary condition is a read access error, as it's a (const char *). My educated guess would be that it would test whether the first character is $ or not, and if not take the first two characters as the salt to DES-crypt. If it is, I'm guessing it just looks for two more $... probably also verifying that the intervening characters are valid base64 (./) characters.
In any case, the data in the password database should be pretty trustworthy. If it's not, you've _probably_ got bigger problems than people trying to exploit calls to crypt.
Best, Leon