From 65c10f6d334b4e6c9879de96fef092bb72afc758 Mon Sep 17 00:00:00 2001 From: Peter Wemm Date: Thu, 28 Dec 2000 11:23:01 +0000 Subject: [PATCH] Hindsight is wonderful, but I got cold feet over the crypt(3) default so I am backing it out for now. The problem is that some random program calling crypt() could be passing a DES salt and the crypt(3) library would encrypt it in md5 mode and there would be a password mismatch as a result. I wrote a validater function for the DES code to verify that a salt is valid for DES, but I realized there were too many strange things to go wrong. passwd(1), pw(8) etc still generate md5 passwords by default for /etc/master.passwd, so this is almost academic. It is a big deal for things that have their own crypt(3)-ed password strings (.htaccess, etc etc). Those are the things I do not want to break. My DES salt recognizer basically checked if the salt was either 2 or 13 characters long, or began with '_' (_PASSWORD_EFMT1). I think it would have worked but I have seen way too much crypt() mishandling in the past. --- lib/libcrypt/crypt.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/libcrypt/crypt.c b/lib/libcrypt/crypt.c index 989d74539de..6f2846dad72 100644 --- a/lib/libcrypt/crypt.c +++ b/lib/libcrypt/crypt.c @@ -42,11 +42,6 @@ static const struct { char *(*const func)(const char *, const char *); const char *const magic; } crypt_types[] = { - { - "md5", - crypt_md5, - "$1$" - }, #ifdef HAS_DES { "des", @@ -54,6 +49,11 @@ static const struct { NULL }, #endif + { + "md5", + crypt_md5, + "$1$" + }, { NULL, NULL