Peter Wemm 65c10f6d33 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.		2000-12-28 11:23:01 +00:00
..
crypt-md5.c	Merge into a single US-exportable libcrypt, which only provides	2000-12-28 10:32:02 +00:00
crypt.3	Merge into a single US-exportable libcrypt, which only provides	2000-12-28 10:32:02 +00:00
crypt.c	Hindsight is wonderful, but I got cold feet over the crypt(3) default	2000-12-28 11:23:01 +00:00
crypt.h	Add working and easy crypt(3)-switching. Yes, we need a whole new API	2000-08-22 02:15:54 +00:00
Makefile	Merge into a single US-exportable libcrypt, which only provides	2000-12-28 10:32:02 +00:00
misc.c	Big code cleanup. (Inspired by Brandon Gillespie). Also move as	1999-09-20 12:45:49 +00:00