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.

1 files changed, 5 insertions, 5 deletions

diff --git a/lib/libcrypt/crypt.c b/lib/libcrypt/crypt.c
index 989d745..6f2846d 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",
@@ -55,6 +50,11 @@ static const struct {
 	},
 #endif
 	{
+		"md5",
+		crypt_md5,
+		"$1$"
+	},
+	{
 		NULL,
 		NULL
 	}