local my_make_scrambled_password() != mysqlclient's my_make_scrambled_password()

[panlinux]

I think there is some confusion going on, even upstream, regarding these functions that unfortunately have very similar (long) names:
make_scrambled_password()
my_make_scrambled_password()
my_make_scrambled_password_sha1()

This is the current status:
make_scrambled_password(): wrapper for my_make_scrambled_password_sha1(). Produces hex text output.
my_make_scrambled_password(): something entirely different. Produces a non-hexified hash
pam_mysql's my_make_scrambled_password(): seems to mimick upstream's my_make_scrambled_password_sha1()

Bottom line, using upstream's my_make_scrambled_password() with a 42 byte buffer will lead to buffer overflows since it is not the same as my_make_scrambled_password_sha1() or the one reimplemented in pam_mysql.c. Upstream's my_make_scrambled_password() takes a CRYPT_MAX_PASSWORD_SIZE len buffer and does not produce the same type of value that is stored in the table when the PASSWORD() SQL function is used.

I think upstream is nowadays just not exporting the correct function. They should probably export make_scrambled_password() which maps to my_make_scrambled_password_sha1(), but it's messy now. I added a comment to #80974

For pam_mysql, I suggest to use make_scrambled_password() from mysqlclient if it exists, and if not reimplement it as you are doing now, but with the name make_scrambled_password.

Last but not least, even if it weren't for the overflow problem, the authentication will never work because the output of my_make_scrambled_password() will never match the hexified hash stored on the server.

[panlinux]

I believe this can be closed now? Or is it missing a merge against a particular branch? Or a new 0.8 release perhaps?

[NigelCunningham]

New 0.8 release coming :) Thanks.