freebsd-nq/lib/libcrypt
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
Makefile Merge into a single US-exportable libcrypt, which only provides 2000-12-28 10:32:02 +00:00
misc.c